| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There will be two call sites to demonstrate it.
Eventually maybe this will want to be in tor-basic-utils, since it
doesn't depend on any of the tor-netdoc types. But it would be
sensible to wait until the situation with PeekableIterator and
Itertools is improved.
For now we make this #[doc(hidden)] to avoid it becoming part of our
stable API.
|
| | |
| |
| |
| |
| | |
This will avoids some hairy borrowck disasters when we try to use
iterator adapters.
|
| | |
| |
| |
| | |
Not xure how my MR to try to do this everyone missed this one.
|
| | |
| |
| |
| | |
Not xure how my MR to try to do this everyone missed this one.
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This one was generated (by dgoulet) using `ClientDescEncKey`
encryption. Its information is:
```
Address: paozpdhgz2okvc6kgbxvh2bnfsmt4xergrtcl4obkhopyvwxkpjzvoad.onion
Time period: 19397
Client:
paozpdhgz2okvc6kgbxvh2bnfsmt4xergrtcl4obkhopyvwxkpjzvoad:descriptor:x25519:SDZNMD4RP4SCH4EYTTUZPFRZINNFWAOPPKZ6BINZAC7LREV24RBQ
Service:
descriptor:x25519:SACGOAEODFGCYY22NYZV45ZESFPFLDGLMBWFACKEO34XGHASSAMQ
```
|
| |\
| |
| |
| |
| | |
Compute the HS directory hash ring
See merge request tpo/core/arti!1012
|
| | |
| |
| |
| |
| |
| | |
* Provide an accessor for the HSDIR flag
* Provide a function for testing a relay for hsdir inclusion
* Provide an iterator on NetDir that returns the hsdirs
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
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
|