| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
Done using:
```
for crate in $(./maint/list_crates | rg '^(tor|arti-)'); do
cargo set-version -p $crate 0.40.0
done
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The non-{arti-,tor-} crates are:
```
./maint/list-crates | rg -v '^(tor|arti)'
oneshot-fused-workaround
slotmap-careful
test-temp-dir
fslock-guard
hashx
equix
caret
fs-mistrust
safelog
retry-error
futures-copy
```
Because this release bumps the MSRV, I am bumping the minor version of all of
them.
MINOR="
oneshot-fused-workaround
slotmap-careful
test-temp-dir
fslock-guard
hashx
equix
caret
fs-mistrust
safelog
retry-error
futures-copy
"
for crate in $MINOR; do
cargo set-version --bump minor -p $crate;
done
```
|
| |
|
|
|
|
|
| |
It was _target before because we had it in the function with a
cfg_if!(). Now don't so no need.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| |\
| |
| |
| |
| | |
chanmgr: Store our relay addresses in the builder
See merge request tpo/core/arti!3716
|
| | |
| |
| |
| |
| |
| | |
No need to pass from the arti relay binary our addresses when handling
an incoming channel, use the one in the channel builder that an
initiator channel uses.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We need those addresses when we build a relay channel in order to send
them into our NETINFO cell.
This adds the `with_my_addrs()` on the `ChanMgrConfig` object. Next
commit will make arti-relay use it.
Signed-off-by: David Goulet <[email protected]>
|
| |/
|
|
|
|
|
|
|
|
| |
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]>
|
| |
|
|
|
|
|
|
|
|
| |
The arti-relay crate rotates the keys at regular interval which we need
to give to the ChanMgr to update its builder.
This function boldly replace the default factory with the new identities
including the TLS acceptor can pick up the new key.
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]>
|
| |\
| |
| |
| |
| | |
Port several crates to derive_deftly(TorConfig)
See merge request tpo/core/arti!3691
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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]>
|
| | |
| |
| |
| |
| |
| |
| | |
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]>
|
| |/
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |\
| |
| |
| |
| |
| |
| | |
Mr 3616 rebased
Closes #1800
See merge request tpo/core/arti!3681
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | | |
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.
|
| | |/
| |
| |
| |
| |
| |
| | |
As agreed at our last team meeting.
See
https://gitlab.torproject.org/tpo/core/arti/#minimum-supported-rust-version
|
| |\ \
| | |
| | |
| | |
| | | |
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]>
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
tor-chanmgr: Add additional `get_or_launch()` tests and update doc comment
Closes #2344
See merge request tpo/core/arti!3676
|
| | | |
|
| | |
| |
| |
| |
| | |
When there are two channel requests with the same identities and
different socket addresses, we return the same channel.
|
| |\ \
| |/
|/|
| |
| | |
Implement channel canonicity
See merge request tpo/core/arti!3668
|
| | |
| |
| |
| | |
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When connecting, we pass an OwnedChanTarget that can contain a list of
IPs of the relay we want to connect to. The connect() picks one and
return the actual OwnedChanTarget used as in the real IP address we are
using.
From that point on, we must only use that as the channel canonicity
requires to check against the IP we believe we are connected to.
This also is much better to use for error handling considering the error
is on the actual channel target, not the hypothetical one.
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
All handshake pass the NETINFO cell, the advertised addresses (if any)
and the peer address in order to build the Canonicity and build the
channel with it.
In order to pull this off, the "my_addrs" were added to several object
along the NETINFO cell.
We also pass the channel method when connecting (initiator) to a relay
as we need this for this canonicity build.
Signed-off-by: David Goulet <[email protected]>
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
We will want our channel selection functions (`open_channel_is_allowed`,
`pending_channel_maybe_allowed`, and `choose_best_channel`) to inspect
the requested target addresses in the future (see their TODOs), so these
functions need to take a `HasAddrs` to get those addresses.
|
| |/
|
|
|
| |
This will be needed later so that our channel selection functions can
take a `HasAddrs`.
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|