| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
This adds the trait type `ListenOptions` to `NetStreamProvider` and adds
this `ListenOptions` as an argument to `NetStreamProvider::listen()`.
You probably want to look at the changes in tor-rtcompat first, then the
rest of this commit is updating the various places we use
`NetStreamProvider`.
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
For now this just sets up the structure. We'll add options for TCP
later.
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
This better matches nearby code.
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Previously when initializing a stream, we constructed most of the
stream-related queues outside of the reactor and passed the relevant
halves of the queues (senders or receivers) into the reactor.
A downside of the above approach is that the reactor may be better
informed about what queues to construct, and how to construct them. For
example the reactor knows what type of flow control that the hop is
using, so it knows whether we need queues for passing rate limits and
drain rates for XON/XOFF flow control.
This commit moves the construction of these queues into the reactor and
passes the relevant halves out of the reactor. In the future we can make
better decisions about which queues are needed depending on the flow
control method used instead of always constructing them (see arti#2068).
Reviewing with `--color-moved` might be helpful as a few lines have been
moved.
|
| | |_|/ / / / /
|/| | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Whether a stream queue should be bounded or unbounded is a decision that
needs to be made at runtime depending on the type of flow control used,
not at build-time. Window-based flow control should be bounded and
XON/XOFF flow control should be unbounded.
If we wanted to support both bounded and unbounded queues, it would take
a bunch of boilerplate code to wrap the senders and receivers in enums.
Instead we make the queue always bounded, but use a large bound for
XON/XOFF flow control.
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The stream queue length (for messages incoming from the Tor network)
depends on the type of flow control we're using for the hop. Currently
we construct the stream queue outside of the circuit reactor, but we
don't have the flow control information here.
Instead of constructing the stream queue outside of the reactor and
passing the sender into the reactor, we construct the stream queue
inside of the reactor and pass the receiver out of the reactor.
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The common suffix isn't needed.
|
| |\ \ \ \ \ \ \
| |_|_|_|/ / /
|/| | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
tor-proto: Don't run vegas algorithm when a clock stall/jump was detected
Closes #2504
See merge request tpo/core/arti!3967
|
| | | | | | | | |
|
| | | | | | | | |
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
keymgr: more docs for the `RawEntryId` APIs, and some dead code removal
See merge request tpo/core/arti!3997
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
These are unused, and I don't think they're needed by our API users
either, since `KeystoreEntryResult` is just a type alias for `Result`.
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
`RawKeystoreEntry` no longer exists, so these tests need to be updated.
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
I think this adds unnecessary indirection, and it's a bit confusing to
have two separate keystore entry types (we have `KeystoreEntry` too).
This type exists just to server as a wrapper over the `RawEntryId` of an
unrecognized keystore entry, and the `KeystoreId` of the keystore it was
found in.
This commit folds `RawKeystoreEntry` into `UnrecognizedEntry`, which was
previously a thin wrapper over `RawKeystoreEntry`.
|
| |\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Implement Elliptic Curve Certificates for Router Descriptors
See merge request tpo/core/arti!3939
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
This commit removes the Ed25519 round-trip verifciation in certificate
creation because it reduces the code complexity and is pretty uncommon
in cryptographic code.
|
| | | | | | | | | | |
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
This commit tests an invalid certified key type by adding a test that
does not use CertifiedKey::Ed25519.
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
No functional change.
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
This commit adjusts the tests to make it possible to add a test for a
non-matching certified key type.
For this, we simply store the certified key as a CertifiedKey and not as
an Ed25519Identity. Inevitably, this requires us to "force" create such
an identity on the fly in order to test the mismatch, which is fine
because it is an edge-case anyways.
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Fixes the numbering due to a recently added additional check.
Review using --word-diff=color.
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
This commit properly verifies the certified key type by not returning a
bug but rather invalid data in the case of the certified key not being
an Ed25519 key.
Tests and number adjustments will follow.
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
This commit adds a new type, Ed25519FamilyCert, which works very similar
to Ed25519IdentityCert, except that it supports family certificates.
A notable difference is, that the identity key must be provided during
verification because it does not make sense to verify these certificates
without it.
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
This commit implements the Ed25519IdentityCert type using EmbeddableCert
logic that was introduced recently. These certificates contain the
identity key and the signing key of a relay and the type provides two
methods: .verify() for verification and .new_signed() for construction.
Besides, edcert::* is now made public as this is required now given that
it contains public types.
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
This commit adds the test utilities required for testing the
yet-to-be-implemented Ed25519IdentityCert and Ed25519FamilyCert types,
whose interface largely overlaps, making a test "framework" useful to
avoid code duplication.
Their interfaces consist of two functions:
* `.verify(Ed25519Identity, KeyUnknownCert, Duration, SystemTime)`
* Verifies a KeyUnknownCert whether it is valid, given a SystemTime
plus post valid tolerance alongside a well-known identity key in
the case of family certificates.
* `.new_signed(&ed25519::Keypair, Ed25519Identity, SystemTime)`
* Creates a new certificate from a signing keypair plus a certified
key alongside a SystemTime at when this certificate will expire.
The commit introduces a testing trait that will be implemented for both
types once added. Then, there are two generic tests that test the
generation and verification of a valid random one as well as a test that
tests violation of various constraints common to these certificates.
The generic trait is most notable for the .new_signed() and .verify()
method which we are roughly documented. Please see the next commit for
a concrete example if understanding is hard.
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
This commit moves the documentation for FromIterator<RelayFamilyId> for
RelayFamilyIds to the type level documentation of RelayFamilyIds. It
also rephrases the comment to fit in there more nicely grammatically and
contextually, as a pure motion of the comment would not have been
helpful to have there in any circumstance.
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Adds a TODO with regard to .sort() and .dedup() in FromIterator in
RelayFamilyIds and the fact that it is slightly weird. This is not a
new problem with the type but stems from the fact that it tries to
emulate a BTreeSet inside a Vec which is not nice.
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
While already here, do this change, in case it becomes useful later on.
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
This makes working with this more comfortable as those calls are
generally required anyways.
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
RsaIdentity implements Copy itself so it makes sense to derive it on
those wrappers too.
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Helpful in tests instead of Deref.
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Fixes an outstanding TODO.
|
| |/ / / / / / / /
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
We will need an inverse of the existing From implementation so that
derivation makes sense because we will obtain it for free then.
|
| |\ \ \ \ \ \ \ \
| |/ / / / / / /
|/| | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Hopefully non-controversial parts of RPC configuration prep work
Closes #2532
See merge request tpo/core/arti!3979
|