| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
| |
The bridge descriptor manager is going to want this.
|
| |
|
|
|
| |
These are needed to actually be able to build circuits through
a bridge.
|
| |
|
|
|
|
|
|
|
| |
To implement a reasonable RsaIdentity accessor, we have to
store the RsaIdentity in the RouterDesc, or else we'd have to
recalculate it using SHA1 and DER every time.
The Ed25519 identity is hidden inside the identity cert, but it's
safe to get a reference to it.
|
| |
|
|
| |
Their omission was an oversight.
|
| | |
|
| |
|
|
| |
and propagate to other affected crates
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Some of these were for decoding particular objects (we now say
what kind of objects), and some were unrelated tor_cert errors that
for some reason we had shoved into a tor_bytes::Error.
There is now a separate tor_cert::CertError type, independent from
tor_cert's use of `tor_bytes::Error` for parsing errors.
|
| |
|
|
| |
It's a little overzealous sometimes, but it's mostly to the good.
|
| |
|
|
|
|
|
|
|
|
| |
Relay nicknames are always between 1 and 19 characters long, and
they're always ASCII: That means that storing them in a [u8;19] will
always be possible, and always use less resources than storing them
in a String.
Fortunately, the tinystr crate already helps us with this kind of
thing.
|
| |
|
|
|
|
|
|
| |
This commit uses the `visibility` and `visible` crates to
conditionally make certain structs and their fields public
(respectively). This is incredibly dangerous to use for anything
besides testing, and I've tried to write the documentation for the
feature accordingly.
|
| |
|
|
|
|
|
|
| |
This should save around 1MB per consensus, since every relay has a
'protocols' lines, but there are only a few distinct possibilities
for such a line.
Closes #385.
|
| |
|
|
|
|
| |
This should save 1-3 MB of ram on each running arti client.
Closes #384. See also tor#27359 and proposal 298.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This error type doesn't impement HasKind, since the kind will depend
on context.
However, the existing implementation was pretty messy and inconsistent:
Some errors had positions, some didn't.
Some took messages as str, some as String.
Some had internal errors that were somewhat orthogonal to their actual
types.
This commit refactors tor_netdoc::Error to use a ParseErrorKind, and
adds a set of convenience functions to add positions and
messages to the errors that need them.
|
| |
|
|
|
|
| |
Our behavior in handling not-yet-valid router descriptors doesn't match
the C Tor implementation, but it's not a big deal:
we don't currently use router descriptors at all.
|
| |
|
|
|
|
| |
If we fail to convert a curve25519 key to an ed25519 key for checking
the onion-key crosscert, don't call that an internal error: it means
that something is wrong with the provided ntor key.
|
| |
|
|
|
| |
As of tor-spec commit 01122c5bd7d2f0f, the spec is no longer ambiguous
on this point.
|
| |
|
|
|
|
|
| |
Also fix a couple of warnings introduced by now-unneeded imports
with new ed25519 crate.
This is part of the process for releasing our next version.
|
| |
|
|
|
|
|
|
|
|
| |
Nothing in arti currently uses this document type. Eventually it
will be useful for relays and for bridge clients.
I've left the "SHA1 digest of a router descriptor" type available
unconditinoally, however, since it does get used in a few places.
Part of #125.
|
| | |
|
| | |
|
|
|
This will cause some pain for now, but now is really the best time
to do this kind of thing.
|
