| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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.)
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Onion service descriptor parsing and decoding, first cut.
See merge request tpo/core/arti!999
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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.
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Also, explain why a few of these certificates aren't actually useful
as certificates. (This issue is also documented in torspec!110)
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This allows us to run `is_valid_at` and friends on the certificate
itself, which we will use soon in hsdesc validity checks.
|
| | | | | | |
|
| | | | | | |
|
| |\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | | |
tor-netdoc: Suppress a cfg-dependent dead code warning
See merge request tpo/core/arti!998
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is dead code when
cargo +stable clippy -p tor-netdir --all-features --all-targets
|
| |\ \ \ \ \
| |_|/ / /
|/| | | |
| | | | |
| | | | | |
tor-linkspec: LinkSpec parsing: use read_nested_u8len
See merge request tpo/core/arti!1007
|
| | | | | | |
|
| |/ / / /
| | | |
| | | |
| | | | |
This eliminates hardcoded length values.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
tor-netdir: Use typed-index-collections for router status index
See merge request tpo/core/arti!1004
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Always use "index" and not "position".
Remove wording which is otiose given the type name.
|
| | | | | | |
|
| | | | | | |
|
| |/ / / /
| | | |
| | | |
| | | |
| | | | |
Call it everywhere instead of the inherent method on MdConsensus.
(Verified by ad-hoc temporarily renaming MdConsensus::relays().)
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Fix a couple of minor issues
See merge request tpo/core/arti!1003
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is dead code when
cargo +stable clippy -p tor-netdir --all-features --all-targets
|
| |/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/issues/756
I think this is going in the wrong direction, but it is better to fix
it so that the names agree for now, pending a decision on the naming.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Report causes of errors
Closes #680
See merge request tpo/core/arti!997
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Split off for ease of review and possible rebase.
|