* It is the NetDir's responsibility to tell the caller what the time
period is.
* There can be up to two secondary time periods.
* Each time period has a single SRV.
* Secondary time periods only apply for onion services, when they
publish.
* When publishing, the correct input is a time period.
These are a bit complex internally, but the API they present is
pretty simple. I've left some discussion of points where the design
isn't totally fleshed out, and where we need to look harder at the
spec.
Part of #716.
SharedRandVal now holds only the 32-byte random value itself; the
"number of commits" field is in SharedRandStatus.
This commit also makes the SharedRandVal be exactly 32 bytes, since
we've set it to that value in the spec.
On 1.22, cargo audit is complaining about RUSTSEC-2023-0001.
We aren't affected, since we don't use windows named pipes (yet),
but let's make cargo audit happier.
"quicktest" is meant to build faster than our (tuned for size above
all) release profile, while having enough optimization to perform
reasonably well when used for testing.
Closes#639.
This module has types and operations needed in multiple places
for an onion service implementation. There are a bunch of
TODO hs-crypto comments that we'll need to fill in.
The `Ed25519Identity` and `RsaIdentity` types are not precisely
always used as relay identifiers: they are more generally used as
_key_ identifiers.
This will become relevant as `RsaIdentity` is used for authority
keys (as in authorities' VoterInfo blocks), and as `Ed25519Identity`
is used as the identifier behind an onion service key.
This is based on logs that I added locally while I was trying to
debug some startup issues. Hopefully they'll make things easier the
next time there's something to debug.
Part of #677.
Closes#719.
Due to a difference between ed25519-dalek and ed25519-donna,
converting these secret keys directly to public keys does not work.
I've documented this in a "Limitations" section.
Specifically, I'm adding a high-level MDD (simplified for clarity).
I'm also adding a diagram of the object relations among our manager
types. (There are also communications that happen via channels, but
those aren't discussed here.) That part closes#624.
There is probably more to say here, but this should form a scaffold
we can build on.
This type provides a common implementation for types that are
implemented as arrays of bytes that should only be compared
with constant-time comparisons.