| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | |
| |
| |
| | |
As far as we can tell, this never existed.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
(I think it's okay to omit the Hs here, since this type is not
visible outside the hsdesc parsing code. I'll rename if others
disagree.)
|
| | | |
|
| |/
|
|
|
|
|
|
|
| |
Generated with perl:
s/K([PS])_hs_intro_tid/K$1_hs_ipt_sid/g;
s/K([PS])_onion_ntor/K$1_ntor/g;
s/K([PS])_hs_intro_ntor/K$1_hss_ntor/g;
s/K([PS])_hs_desc_ephem/K$1_hss_desc_enc/g;
|
| | |
|
| | |
|
| |
|
|
|
|
| |
We need to make sure any `#[cfg(feature=...)]` attributes are
applied not only to our variant declarations, but also to the
branches in the match statements that deal with them.
|
| |
|
|
| |
Thanks to rust-analyzer for making this simple.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This is the main implementation part of #525.
|
| |
|
|
|
| |
Previously, there were some unit variants, but that makes things
quite awkward for #525.
|
| |
|
|
|
|
|
|
| |
Doing this will make it much easier to implement a macro that
generates restricted instances of the Msg types (for #525).
The Body change is a breaking change. I don't think anybody else
implements Body, but in theory they could.
|
| |
|
|
|
|
|
| |
These are generalizations of RelayCell and ChanCell respectively,
that allow using an arbitrary message type in place of the fully
general RelayMsg and ChanMsg types. Doing this is a prerequisite
for usefully implementing arti#525.
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
Create and use an ErrorHint type to report how to fix a problem.
Closes #579 and #578
See merge request tpo/core/arti!994
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
Change ErrorHint so that, internally, it just holds an enum with a
lightweight reference to whatever parts of the error it needs to
generate a hint. Then we can move the formatting logic into a
Display function for ErrorHint, and do away with ErrorDetail entirely.
|
| | |
| |
| |
| |
| |
| |
| | |
Move the "hint" function into Error, and use Option rather than Result.
(I'm using Option here because it's not really an error case not to have
a hint; we just either have a hint, or we don't.)
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Fix AuthCert behavior on unrecognized tokens, and prevent bug from recurring elsewhere.
Closes #752
See merge request tpo/core/arti!1006
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Now we require that, for all `SectionRules`, either the caller say
how to handle unrecognized tokens (using `.add(UNRECOGNIZED...)`),
or that they explicitly reject unrecognized tokens (using
`reject_unrecognized`()`.)
This solution uses an assert!() rather than an Error to indicate
failure. I say that's fine, since
1. This is a crate-internal API.
2. We never dynamically construct SectionRules according to
different behavior: they are always prefabricated in a fixed
code block. Thus, if we test a parser at all, we will make
sure that its SectionRules are well-formed.
I considered and explicitly rejected a solution where the builder
had to be finalized with separate methods `build_strict()` or
`build_tolerant()`: It's too easy IMO for the caller to forget what
these call means.
Prevents further recurrences of #752.
Closes #752.
|
| | | |
| | |
| | |
| | | |
No new behavior yet.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This fixes an instance of bug#752. Previously, we would reject any
AuthCert that contained an unexpected keyword. (Fortunately, this
data format does not change very often.)
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
In the process I found a couple of keys without identifiers in the
spec.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
These functions consume a checkable wrapper, and return a new
checkable wrapper with mapped contents but the same not-yet-checked
constraints.
As documented, They are "dangerous" because the provided function
gets access to the contents before they are checked; the caller has
to make sure that the provided function doesn't expose their
contents inappropriately.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
There are some places where I note certificates which are not
currently validated, because there is no cryptographic point in
doing so. We should either document that this is okay, or validate
the certificates anyway.
This code might benefit from refactoring to make it prettier.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
It turns out that C Tor doesn't add a newline at the end of the
middle layer of an onion service descriptor. I've made a spec MR
(torspec!109) to document this: here, it's time to work around the
issue.
|