Method dispatch rules mean that if the receiver type of the actual
function changes, `self.call()` can turn into a purely-recursive call
which overflows the stack.
Async Rust doesn't have the usual warning for this situation :-(.
UFCS is clumsier but doesn't have that problem because it involves
much less magical dispatch. Instead of generating a recursive call
which overflows the stack, it fails to compile.
Fixes warning from
cargo -o doc --document-private-items --all-features --workspace
This was evidentlhy overlooked during recent replacement of unescorted
private keys in the code.
I could also have stopped using `::default()` to construct this
(testing-only) object, but I think it makes more sense to turn it
into a non-unit object.
- We make the tor-guardmgr "We have found that {} is usable" line
include the word "guard", otherwise it doesn't appear very useful to a
user in safe logging mode, since the guard gets replaced with
[scrubbed].
- The "Actually got an end cell..." message is downgraded to DEBUG.
Per #798, we want to make sure that we never pass around an
`ed25519::SecretKey`; only an `ed25519::Keypair` (or
`ExpandedKeypair`). This is because, when you're computing an
ed25519 signature, you have to use the public key as one of your
inputs, and if you ever use a mismatched public key you are
vulnerable to a nonce reuse attack.
(For more info see
https://moderncrypto.org/mail-archive/curves/2020/001012.html )
This is like an `ed25519::Keypair`, except that instead of a
`SecretKey` it contains an `ExpandedSecretKey`.
We'll be using this to implement #798, where we impose a rule that
there must be no "unescorted" ed25519 secret keys.
We never want to create one of these from its parts except when we
are testing it; we only want to forward an Introduce1 message with a
new command on it.
There were two bugs here that made the behavior unlike that of C
tor: we had swapped the MAC inputs, and we had forgotten to include
the public key X in the input.
I think that these Input structs had been defined so that we could
use hs_ntor interchangeably with other handshakes. The trouble is,
though, that it doesn't really work like any other handshakes we
have.
Note that some of the invocations for this function seem to put the
key and the message in a questionable order. But that's a thing to
figure out later, while debugging.
We'll want this because our hs_ntor handshake requires access to an
encoded version of the header independent from the actual encrypted
message.
part of #866.
This commit changes certain log messages to debug for recoverable errors
and a warn if all such attempts fail, in order to not clutter up the
info messages that end users get to see.
This function will be used to look up a relay by a set of LinkSpecs
given from an incoming HsDesc or INTRODUCE2 message. It differs
from other "lookup relay by IDs" functions in that it needs to be
able to return "here's a relay", "couldn't found a relay", or
"learned that this relay is impossible."
Closes#855: This is the only new API needed for ChanTarget
validation, I think.
Ian Jackson
Nick Mathewson
Ian Jackson
eta
gabi-250
Saksham Mittal