(I'm not removing it entirely since maybe we _should_ use it, and
maybe we _will_ as we do services. I've added a TODO HS for
removing it or using it, and removed the TODO HS at the head of
pk.rs about making sure that all the key types in the module really
belong there.)
This test is known to fail "when the load is high". Recently I had to
press the "merge unverified changes" button to merge !1238, after four
consecutivew spurious failures.
IMO this is intolerable.
I think it isn't actually a great idea for HsIdParseError to
implement ErrorKind, since the actual ErrorKind would depend
entirely on where the problematic ID came from.
The type is a bit odd but this is a result of the underlying protocol.
I don't feel like inventing `IntroduceAckSuccess` that contains only
the extensions.
Onion service hops (pointlessly) use SHA3-256 for their
authentication, but they truncate it to 20 bytes (assuming I'm
reading the C right.)
See torspec#204 for clarification here.
This is a rather tricky piece of functionality. It works as
follows.
We introduce a `CastTable` type. Each `CastTable` tells us how to
downcast `dyn Object` for objects of a single concrete type.
The `Object` type now has a `get_casttable` method that returns
an empty `CastTable` by default.
`CastTable` is, internally, a map from the `TypeId` of the target
dyn Trait reference type to a function
`fn(&dyn Object) -> &dyn Trait`. These functions are stored as
`Box<dyn Any + ...>`. (They are Boxed because they may refer to
generic functions, which you can't get a static reference to,
and they're Any because the functions have different types.)
The `decl_object!` macro now implements `get_casttable` as
appropriate. (The syntax is a bit janky, but that's what we get
for not using derive_adhoc.) For non-generic types, `get_casttable`
uses a Lazy<CastTable>`. to initialize a CastTable exactly once.
For generic types, it use a `Lazy<RwLock<HashMap<..>>` to
build one CastTable per instantiation of the generic type.
This could probably be optimized a bit more, the yaks could be
shaved in a more scintillating hairstyle, and the syntax for
generic `decl_object` could definitely be improved.
This code tries to fill in some TODO HS code, replacing it with a
lot more code with a bunch more TODO HS comments. Hopefully the
expansions of the new TODO HS comments should be simpler.
We want the ability to send the same handshake request in parallel
on multiple introduce circuits. This implies encoding the client
handshake more than once.
(Sadly we can't _actually_ do this in the protocol as it stands,
since the onion service can use a separate KP_hss_ntor for each
introduction point; I'll add a comment to that effect later.)
We need the fix from [82d69902], which first appeared in async-trait
version 1.54. (Technically we only need this fix in tor-hsclient,
but we may as well update our minimal async-trait version everywhere.)
[82d69902]: 82d6990253