| Commit message (Collapse) | Author | Age | Files | Lines |
| |\
| |
| |
| |
| | |
relay: Couple fixes related to channel creation
See merge request tpo/core/arti!3726
|
| | |
| |
| |
| | |
Signed-off-by: David Goulet <[email protected]>
|
| | | |
|
| |/
|
|
|
|
|
| |
Before this commit, we would use the RsaIdentity which is a SHA1 digest.
We do the same for the peer RSA key.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
| |
It was all commented out until now that we have a final
RelayIdentities.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
| |
Closes #1601
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
```text
Completed handshake with Ed25519Identity { ClByyE4zT+p3dudeCVkUfVA1zp2y2sOUe7u/HHLliWU } [(RsaIdentity { $547bb37f9cd8079eaf1cfcb73fff5887d6f58138 }, [9, 111, 131, 62, 212, 144, 149, 88, 211, 87, 175, 114, 18, 111, 189, 36, 205, 21, 66, 205, 217, 176, 139, 130, 70, 211, 40, 130, 79, 29, 144, 179])]
```
After:
```text
Completed handshake with ed25519:wo9NA5RXkPAc7sB2301JBpvdk1RvSOGZEzgwuWP/msA [$feebaba2b6faf53ae1dc8dda8681ce026537dfa4]
```
|
| |
|
|
|
| |
These were previously in a single `Option`, but now that the `Option`
was removed, I think it's nicer to make these separate fields.
|
| |
|
|
|
|
| |
I don't think that the `Option`s are needed anymore, since
unauthenticated channels no longer transition through the
`VerifiedChannel` state.
|
| |
|
|
|
|
|
|
|
|
| |
The validate_relay_target() is meant to probably have more checks in the
future hence the vagueness of it instead of being specific to the goal
of this patch.
Closes #1699
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
| |
This commit also adds the TlsKeyAndCert to the identities so the TLS
acceptor can set it up.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
Responder relay handshake requires the peer address at the very start as
it sends its NETINFO right away.
For initiators, we only need it during the finalization process which is
when the NETINFO is sent and the Channel is created.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
| |
This is a large change but it is basically using PeerAddr in the channel
builder through the channel handshake code and into the Channel itself.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The plan is to create PeerInfo when we do a transport connect() which
indicates the exact values that are being used for to connect to the
peer.
We'll then put this struct in the Channel so we can use it when picking
the best channel in the ChanMgr.
Unfortunately, the OwnedChanTarget has a confusing and even possibly
wrong API from which we can't have guarantees.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |\
| |
| |
| |
| |
| |
| | |
proto: Replace circuit-scoped `CircSyncView` with per-hop alternative
Closes #2351
See merge request tpo/core/arti!3680
|
| | | |
|
| | |
| |
| |
| |
| | |
The `CircHopSyncView` is now the view of a hop, not of the whole
circuit.
|
| | | |
|
| | |
| |
| |
| | |
And update the docs
|
| | | |
|
| | |
| |
| |
| |
| | |
Now that CircSyncView no longer needs to know the total number of
streams, we can use it in the new per-hop stream reactor design.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`IncomingStreamRequestFilter`s, and `CircSyncView`s, by extension, are used
both by old relay implementation and the new one for implementing an
out-of-reactor way of deciding how to handle an incoming stream.
In the new circuit reactor design, we have a separate stream reactor for
each hop. Upon receiving an incoming stream, the stream reactor will
need to build one of these `CircSyncView` objects, and then pass it to
an externally-provided `IncomingStreamRequestFilter`. Before this
change, `CircSyncView::n_open_streams()` returned the total number of
open streams, which wouldn't have worked with the new reactor design,
because the per-hop stream reactor doesn't have a global view of all the
hops, so its `CircSyncView` can't return the total number of streams (at
least not without message passing, or sharing state with the other
stream reactors).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Note: this commit only contains the removal of the old `CircSyncView`,
and it of course doens't compile. A future commit will replace the
removed file with the `syncview.rs` from the client module.
This change is split over two commits because it makes reviewing easier
(`git mv`ing the new file over the old results in a confusing diff,
because `git` refuses to show it as a move).
|
| | |
| |
| |
| |
| | |
This is in preparation for replacing the top-level `CircSyncView` with
it.
|
| | |
| |
| |
| | |
This file will be moved to the top-level `circuit` module soon.
|
| | |
| |
| |
| |
| | |
This will soon replace `CircSyncView` wholesale. The preliminary
renaming will make the future diffs easier to review.
|
| | |
| |
| |
| | |
This will soon be needed for building a `CircSyncView`.
|
| |\ \
| |/
|/|
| |
| | |
Bump MSRV to 1.89
See merge request tpo/core/arti!3684
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
`clippy::collapsible_if` started triggering after bumping the MSRV to
1.88.
Since this triggers from a lot of places, and since there even are a
couple of instances where we explicitly allow `clippy::collapsible_ifs`,
I've opened #2342 for deciding what to do about it.
|
| |\ \
| |/
|/|
| |
| | |
relay: Pass our TLS cert to the responder verify process
See merge request tpo/core/arti!3665
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For the responder to build the authentication data, it needs its own
certificate of the TLS handshake that it is responding to (as a TLS
server).
This resolves an important TODO(relay) in the code.
Signed-off-by: David Goulet <[email protected]>
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
proto: Pass *all* cells to handle_forward_cell()
Closes #2339
See merge request tpo/core/arti!3674
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit 04ab3cd848d7977baf58dd64ebfcad6aa54ecb17.
Reverted because we no longer need to "peek" into the opaque
`CircChanMsg` of a circuit reactor: now the implementation-dependent
part of the reactor is in charge of handling the channel messages,
and extracting `Relay` objects out of RELAY/RELAY_EARLY cells,
which then get processed in the base reactor.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This doesn't need to be part of the `ForwardHandler` trait anymore,
because the base reactor no longer calls it directly (instead
implementations are supposed to handle it internally).
No functional changes here, just code motion.
|
| | |
| |
| |
| | |
Closes #2339
|
| | | |
|
| | |
| |
| |
| |
| | |
Needed because some messages are handled differently depending on the
cell type they originated from (RELAY vs RELAY_EARLY).
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This pushes the RELAY/REALY_EARLY handling inside
`handle_forward_cell()`, which now decodes the relay cells and
* handles them internally, if they are unrecognized
(`handle_unrecognized_cell()`), or
* returns them back to the base reactor if they are recognized
(RELAY and RELAY_EARLY cells are handled the same way by the
base reactor)
|
| | |
| |
| |
| |
| | |
Soon this function will be in charge of decoding the cell too, so it
will need a handle to the `HopMgr` (see `decode_relay_cell()`)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, the implementation-dependent `handle_forward_cell()` handled
all forward cells *except* for RELAY cells, which were handled in the
generic base reactor.
This changes the implementation to pass *all* cells, including RELAY
cells, to `handle_forward_cell()` too. This is needed because both
RELAY and RELAY_EARLY cells need to be handled very similarly: both
can be either recognized or unrecognized, with unrecognized cells
being handled by the implementation-dependent code, and the recognized
ones being sent to the base reactor for handling.
A future commit will update `handle_forward_cell()` to extract `Relay`
object out of RELAY/RELAY_EARLY cells, and return it back to the base
reactor for handling.
|