| 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;
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
We're going to make use of it in all of our tests, so we may as well
expose it to them from hsdesc::test.
|
| | |
| |
| |
| |
| | |
This is tested via a round-trip check, and via a successful
decryption of our example descriptor's outer layer.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I generated this using C tor (latest main) and a Chutney network
about a week ago.
The subcredential is:
78210A0D2C72BB7A0CAF606BCD938B9A3696894FDDDBC3B87D424753A7E3DF37
The HS_blind_id is:
43CC0D62FC6252F578705CA645A46109E265290343B1137E90189744B20B3F2D
|
| |/ |
|
| |
|
|
|
| |
This is dead code when
cargo +stable clippy -p tor-netdir --all-features --all-targets
|
| |
|
|
|
|
| |
These crates had API or behavior changes that may affect downstream
crates. Fortunately, they're all version 0.x, and don't need minor
bumps for this.
|
| |
|
|
|
|
|
| |
These changes influence behavior, but not effect compatibility.
(If I messed up, and any crate except for `arti` has non-breaking
API changes, that's still fine, since they are all version
0.x.)
|
| |
|
|
|
| |
This may be temporary if we wind up converting to CtByteArray,
but for now it's good to be terse.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
These are deliberately unsophisticated accessors, in that they return Option<>
rather than filling in missing values with the documented
fallbacks. It seems better to leave a way to distinguish the absent
case in the API.
|
| |
|
|
|
| |
This breaks some experimental APIs, but since they are experimental
no semver note is needed.
|
| | |
|
| | |
|
| |
|
|
|
| |
This panics on error, and we're fine with a panic on misbehavior in
tests.
|
| |
|
|
|
| |
Clippy now warns about these; I'm not sure how these warnings snuck
up on us.
|
| |
|
|
|
|
|
|
| |
This warning kind of snuck up on us! (See #748) For now, let's
disable it. (I've cleaned it up in a couple of examples, since
those are meant to be more idiomatic and user-facing.)
Closes #748.
|