| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | |
| |
| |
| |
| | |
This gets rid of a lot of manual boolean state variable iterator
stuff.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
```
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
Fixes an instance of #768.
The problem with the test vectors is that I used a random time
period number (1234) and the default-in-tor period length (1440)
without checking whether 1440 _meant_ minutes or seconds. I'll add
another test to Tor to make sure that the time period matches now.
With this change, I can test Tor-generated hsdescs with encryption,
so I'm fairly confident that the new behavior is correct.
|
| |\
| |
| |
| |
| | |
Apply restricted_msg to ChanMsg parts of tor-proto
See merge request tpo/core/arti!1013
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Unlike C tor, we treat unrecognized commands as reason to kill off
the connection entirely. That's fine; if we need to add an
unrecognized command in the future, we can use VERSIONS to negotiate
it.
Also, if someday we want this code to support relay channels as
well, we can use some type trickery to have that work too.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Actually, to avoid making a breaking change, I'm deprecating
BadMessage and creating a new InvalidMessage variant that takes a
Cow. This way I don't need to track every crate that re-exposes
tor_bytes::Error and call this a breaking change in those.
Making this change will allow tor_bytes errors to be much more
helpful.
|
| | | |
|
| | |
| |
| |
| |
| | |
It's now redundant, since `restricted_msg!` defines From and Into
for us.
|
| | |
| |
| |
| | |
This allows us to remove a shenanigan from `restricted_msg!{}`.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Every FooMsg type now implements Into<AnyFooMsg>, and
TryFrom<FooMsg>.
Additionally, it now implements From<X> for every distinct type that
it supports. This last part lets us discard a bunch of code.
Unfortunately, I needed some downright hackish trickery in order to
get these macros to avoid generating `From<AnyFooMsg> for AnyFooMsg`
and conflicting with the blanket implementation.
The trickery to deal with RelayEarly and Relay being the same type
was not necessarily worth it; I will be separating them and removing
said trickery in the next commit.
|
| | |
| |
| |
| |
| |
| |
| | |
This change lets us use ChannelCodec to encode and decode any
restricted channel message type we want. (Later on, we'll turn the
related Codec class in tor-proto into a more type-restricted version
of this.)
|
| |\ \
| | |
| | |
| | |
| | | |
Compute the HS directory hash ring
See merge request tpo/core/arti!1012
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1012#note_2876824
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
Deferred formatting changes which would have obscured the commits they
were prompted by.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
* 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
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* Implement Netdir::compute_rings in terms of a new
HsDirRing::compute, that currently does nothing.
* Actually call Netdir::compute_rings (since now it doesn't panic).
* Make Netdir::compute_rings not be pub. We do this unconditionally,
rather than exposing the distinction between a netdir-without-hsdir
and a netdir-with-hsdir.
|
| | | |
| | |
| | |
| | |
| | | |
This already allows us to get rid of some duplication, and will be
useful more widely in a moment.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
This will allow us to tell if we can reuse parts of a ring.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The file which contains this type is called hsdir_params.rs. We have
a general problem with slight confusion about when to includen "dir"
and when to include "ring".
Resolve this in favour of the rule now added to the module-level doc
comment.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
These variables are going to be struct fields, which will sort of
enforce consistent naming. The struct fields are going to appear in a
moment. We'll call the fields "current" and "secondary" after the
naming in the test cases.
And import hsdir_params::HsRingParams, which we're going to make more
references to.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This will enable us to pass these around more conveniently.
And make empty_from_params take an owned params, which it would like.
|
| | | | |
|
| | | |
| | |
| | |
| | | |
We'll need this shortly.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* Remove the return value, which was not used anywhere.
Also remove the code to calculate the return value.
* Take an Arc<NetDir> rather than a reference. We are going to want
this for HS support. This has no overall effect on the lifetime of
the4 Arc, which was owned at the one call site and then imediately
dropped.
* Change the documentation to explain what the function's role is in
the netdir API, rather than the fiddly details of what it actually
does internally. Relegate the latter to a code comment.
(When we have HS, this will do more, or, at least, make further
arrangements.)
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
This was omitted in !1004. (Because this code isn't actually wired up
yet, it typechecked anyway. But we need to fix it.)
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Locally, the only functional effect is that now we refuse to handle
non-whole-number-of-minutes lengths - but since the consensus
parameter can't represent those, there's no overall functional change.
|
| | | | |
|
| |/ / |
|
| | | |
|
| | | |
|