| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
Done via:
```
for crate in $(./maint/list-crates | rg '^(tor|arti-)'); do
cargo set-version -p $crate 0.39.0
done
```
|
| |\
| |
| |
| |
| | |
fix(minver): Update paste dependency to be minver compatible
See merge request tpo/core/arti!3610
|
| | | |
|
| |/
|
|
| |
This adds the lint to all our crates.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit is a bit loaded but it is coherent.
First, we set Eq and PartialEq to the channel message Authenticate so we
can compare it with the one we expected.
Second, the AuthenticationCell enum is introduced to store either an
AUTH_CHALLENGE or an AUTHENTICATE since one side of the handshake can
only have one. This allows us to store one or the other in
UnverifiedRelayChannel.
Depending on what we have, the authentication process is different as it
dictates which side we are on (initiator vs responder). Keep in mind
that the handshake code enforces receiving a AUTH_CHALLENGE along side
CERTS. And same goes for AUTHENTICATE which means that if we have an
AUTH_CHALLENGE in the UnverifiedRelayChannel, it is certain that the
other side wants to authenticate and we are the initiator.
Finally, the sending of CERTS and AUTHENTICATE by the initiator is now
in UnverifiedRelayChannel::check() done right after verifying the
channel CERTS and holding a "VerifiedChannel" object.
This means that the last piece, sending the `NETINFO` by the initiator
will be done in the check() but in a future commit. This leaves the
VerifiableChannel::finish() to send nothing and only finalize the
channel with the NETINFO (canonicity).
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
Done using the following:
```bash
for crate in $(./maint/list_crates | rg '^(tor|arti-)'); do
cargo set-version -p $crate 0.38.0
done
```
|
| |
|
|
|
|
|
|
|
| |
Fixes part of #2193.
(Edits from nickm: I selected the cases here that I could verify
were correct from immediate context.)
Edited-by: Nick Mathewson <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
We are supposed to pin whenever we enable the `beta` cargo feature,
see
https://docs.rs/derive-deftly/latest/derive_deftly/doc_changelog/index.html#beta-features
Empirically, we somehow failed to do that in tor-circmgr.
In practice not pinning makes little difference since cargo wants to
pick the same version everywhere, but we should be correct. But it is
more maintainable to pin everywhere.
|
| |
|
|
|
|
|
|
|
| |
This has:
* Fixes to hygiene spans from the new modules feature, needed for
my WIP netdoc encoder derive.
* A substantially richer `${error }` construct.
|
| |
|
|
|
|
|
|
|
| |
Done using:
```
for crate in $(./maint/list_crates | rg '^(tor|arti-)'); do
cargo set-version -p $crate 0.37.0
done
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
tor-llcrypto: Stop deriving Deref in CtByteArray
Closes #2172
See merge request tpo/core/arti!3432
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
This has the meta attributes with optional values feature and also
hygiene rework for modules.
The breaking changes don't break arti.
|
| |\ \
| | |
| | |
| | |
| | | |
Bump derive-deftly to 1.4.0
See merge request tpo/core/arti!3448
|
| | |/
| |
| |
| |
| |
| | |
This will let us use the new modules feature.
There are no breaking changes to beta features in 1.4.0.
|
| | |
| |
| |
| | |
Run maint/add_warning
|
| |/
|
|
|
|
|
| |
This seems to depend on cfgs. As I say in #1060, I don't think
precise cfg decoration of imports is sensible.
Also, it shouldn't be my job to fix whatever this is...
|
| |
|
|
|
|
|
| |
```bash
readarray -t publish < <(cargo metadata --format-version 1 | jq -r '.packages[] | select((.id | startswith("path+file:///")) and (.rust_version != null) and (.publish == null or .publish == true or .publish != [])) | .name')
for package in "${publish[@]}"; do echo "$package:"; cargo set-version --bump minor -p "$package"; done
```
|
| |
|
|
|
|
|
|
|
|
|
| |
This commit only adds a struct holding all the authentication data that
needs to be built during the verification process after all handshake
cells needed for authentication have been sent.
It lives in the VerifiedChannel struct so it can be used to build the
AUTHENTICATE cell and be sent before the NETINFO.
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because we've updated our MSRV, we must bump the minor version for every
package.
This was done as follows:
cargo set-version -p arti 1.6.0
cargo set-version -p oneshot-fused-workaround 0.4.0
cargo set-version -p slotmap-careful 0.4.0
cargo set-version -p test-temp-dir 0.5.0
cargo set-version -p fslock-guard 0.4.0
cargo set-version -p hashx 0.5.0
cargo set-version -p equix 0.4.0
cargo set-version -p caret 0.7.0
cargo set-version -p fs-mistrust 0.12.0
cargo set-version -p safelog 0.6.0
cargo set-version -p retry-error 0.8.0
xargs -I P <<END cargo set-version -p P 0.35.0
tor-basic-utils
tor-error
tor-general-addr
tor-geoip
tor-rtcompat
tor-rtmock
tor-async-utils
tor-config
tor-config-path
tor-rpc-connect
tor-log-ratelim
tor-rpcbase
tor-memquota
tor-units
tor-llcrypto
tor-bytes
tor-protover
tor-checkable
tor-cert
tor-key-forge
tor-hscrypto
tor-socksproto
tor-linkspec
tor-cell
tor-proto
tor-netdoc
tor-consdiff
tor-netdir
tor-relay-selection
tor-persist
tor-keymgr
tor-chanmgr
tor-ptmgr
tor-dircommon
tor-guardmgr
tor-circmgr
tor-dirclient
tor-dirmgr
tor-dirserver
tor-hsclient
tor-hsservice
tor-hsrproxy
tor-relay-crypto
arti-client
arti-relay
arti-rpcserver
arti-ureq
arti-rpc-client-core
END
|
| |
|
|
| |
This feature has been removed from nightly, in favor of doc_cfg.
|
| | |
|
| | |
|
| |
|
|
| |
Closes #2107
|
| |
|
|
| |
(This was so much easier than reporting on the send side.)
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Per policy, we bump the minor version of every tor-*, arti-* crate
on each release.
We have updated our MSRV, so we're treating this as a breaking
change for our non-(arti/tor)-prefixed crates too.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The AUTHORIZE cell command is simply reserved but not defined. The tor
specification, at this point in time, is allowing such cell before the
handshake starts but it is very unclear on what ordering is allowed nor
how many can are allowed.
C-tor silents drop them like VPADDING and so clearly unused. Instead of
dealing with it, simply remove its support but keeping its reserved
number.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use the ChannelFrame<> for the entirety of the outbound client handshake
that is the ClientInitiator channel type.
With this change, the codec.rs code is not needed anymore along its
CodecError as well which has been normalized onto the crate::Error
instead in order to simplify error handling and avoid duplication of
error types.
Unit tests have been modified to reflect this change of what can be done
with a channel frame. Also renamed to focus on client behavior.
Part of #1597
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Add is_known_cmd() to the restricted_msg!() macro which can be used to
learn if a specific ChanCmd is part of the restricted set or not.
Then add a simple function to get the link protocol version from a
channel codec.
Part of #1597
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
| |
This caps the PoW effort during sorting, rather than at intake.
This allows us to record efforts that are capped in our metrics
histogram while only recording metrics after the PoW solve has actually
been verified.
|
| |
|
|
|
|
| |
This comment isn't correct if the encode() was given a non-empty buffer
(for example if two cells were written to the same buffer, the second
encode() would be given a non-empty buffer, so `pos != 5`).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, run
```
git grep -l "^edition =" |
xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;'
```
Second, manually verify that all Cargo.toml files have changed,
and nothing else has changed.
Third, run cargo fmt again.
|
| |\
| |
| |
| |
| | |
Resolve a few issues that had been waiting for an MSRV update.
See merge request tpo/core/arti!3129
|
| | |
| |
| |
| |
| |
| | |
I had been planning to use `[]::is_sorted` here, once we had
MSRV >= 1.82, but it turns out that we wanted strictly ascending
sequence, whereas `is_sorted` checks for a non-descreasing sequence.
|
| |\ \
| |/
|/|
| |
| | |
Fix a few TODOs for PoW
See merge request tpo/core/arti!3106
|
| | | |
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
Bump MSRV to Rust 1.85
Closes #2095
See merge request tpo/core/arti!3128
|
| | |
| |
| |
| |
| | |
(We were unable to do this before, since it required a rust version
we didn't have.)
|
| | | |
|
| |/ |
|
| |
|
|
| |
This was accidentally omitted from my version bump script.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Made with the following shell script:
export CARGO='nailing-cargo -Eu'
# Non-functional changes only
maint/bump_nodep hashx
# Special
$CARGO set-version -p arti 1.4.6
# Additional features, no breaking changes, depended on in tree
$CARGO set-version -p safelog 0.4.8
# Unconditional bump to 0.33.0
xargs -I P <<END $CARGO set-version -p P 0.33.0
tor-error
tor-general-addr
tor-geoip
tor-rtcompat
tor-rtmock
tor-async-utils
tor-config
tor-config-path
tor-rpc-connect
tor-log-ratelim
tor-rpcbase
tor-memquota
tor-units
tor-llcrypto
tor-bytes
tor-protover
tor-checkable
tor-cert
tor-key-forge
tor-hscrypto
tor-socksproto
tor-linkspec
tor-cell
tor-proto
tor-netdoc
tor-consdiff
tor-netdir
tor-relay-selection
tor-persist
tor-chanmgr
tor-ptmgr
tor-guardmgr
tor-circmgr
tor-dirclient
tor-dirmgr
tor-keymgr
tor-hsclient
tor-hsservice
tor-hsrproxy
tor-relay-crypto
arti-client
arti-relay
arti-rpcserver
arti-ureq
arti-rpc-client-core
END
|
| |
|
|
| |
No upstream changes that break our code.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
It now performs some validation and can return a `Result`.
We perform validation here since different cell formats may have
different maximum data lengths in the future, and `UnparsedRelayMsg`
doesn't expose the cell format so it's difficult to perform this
validation at a higher layer.
|