| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
```bash
readarray -t bump < <(maint/list-crates | grep -P '^tor-|^arti-')
for crate in "${bump[@]}"; do cargo set-version --bump minor -p "${crate}"; done
```
|
| | |
| |
| |
| | |
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| | |
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| | |
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
We have decided that instead of "uniq_id" in logging, we'll use the
"<domaine>-[<type>]-id" syntax to indicate who is that unique ID.
This commit only renames circuit's unique ID to "circ_uniq_id".
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit only affects logging. Whenever possible, log both the UniqId
and CircId.
This also changes the log lines which is now "uniq_id=" and "circ_id="
as the UniqId is internal and circ_id (CircId) is protocol level.
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A CircId is now a circ_id and a UniqId is a unique_id so we stop
confusing them in the code.
Furthermore, channel_id that are CircId are now circ_id. Channel IDs are
different and encoded internally into a UniqId.
This is the first step to clarify semantic before we change the logging
to log both unique ID and circ ID.
No behavior change.
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| | |
We previously interpreted the rate in the XON message as being Kbits per
second, but it's really Kbytes per second.
|
| | | |
|
| |/ |
|
| |\
| |
| |
| |
| | |
tor-proto: Small improvements to circuit handshake tests
See merge request tpo/core/arti!4254
|
| | |
| |
| |
| |
| | |
Now that we read all of the cells from the connection inspector, we can
reuse the existing channel objects.
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
These TODOs are for client issues, not relay isues.
|
| | |
| |
| |
| | |
Otherwise the new circuit gets closed immediately by the relay.
|
| |\ \
| |/
|/|
| |
| | |
tor-protover,tor-proto: Add and use a new `subprotocol_restricted_set` macro
See merge request tpo/core/arti!4241
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
These help to establish connected channel objects to be used for tests.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
```text
$ cargo test -p tor-proto --features relay
[...]
error[E0405]: cannot find trait `IncomingStreamRequestFilter` in this scope
--> crates/tor-proto/src/circuit/reactor.rs:631:10
|
631 | impl IncomingStreamRequestFilter for AllowAllStreamsFilter {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in this scope
```
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Inbound channel (as responder) don't have a ChannelMethod as they are
not initiating the type of transport to use (PT vs Direct). It would
result in a log line when receiving a channel request:
DEBUG tor_proto::channel::handshake: Completed handshake without authentication to [? ] stream_id=Chan 2
This commit uses the `PeerInfo` which is wrapped in a `MaybeSensitive`
and thus safe to log.
Signed-off-by: David Goulet <[email protected]>
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
align DestroyReason with torspec!490
Part of #2578
See merge request tpo/core/arti!4202
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
`HopSettings::from_handshake_params()` checks that the parameters are
correct, so if there are invalid parameters we should fail early before
we initialize the `CryptStatePair`.
|
| | | |
| | |
| | |
| | | |
This is just to make ntor and CREATE_FAST handshakes consistent.
|
| |/ / |
|
| |\ \
| |/
|/|
| |
| | |
Fix some recently-appearing clippy lints
See merge request tpo/core/arti!4240
|
| | |
| |
| |
| | |
Found by rustdoc.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
The advantage of this over using a `SubprotocolRequest` is that we can
use the type system to ensure it only has subprotocols that are allowed
during a handshake.
|
| | |
| |
| |
| |
| | |
We never used this, it was just needed because we used to convert to a
`CircParameters` which required this.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
... and also remove `CircNetParameters::as_circ_parameters()`.
We used to call `HopSettings::from_params_and_caps()` when handling
incoming circuit requests, but this didn't really make sense because we
already know exactly what settings we want.
The new `HopSettings::from_handshake_params()` takes the exact settings
we want, which means we can also skip constructing a `CircParameters`
and use the raw consensus `CircNetParameters`.
Most of the code in `CircNetParameters::as_circ_parameters()` has been
migrated in some form to `HopSettings::from_handshake_params()`.
|
| |/ |
|
| |\
| |
| |
| |
| | |
tor-netdoc testdata-live: Export for the benefit of other crates
See merge request tpo/core/arti!4229
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
We're about to *use* the fix that was in 1.11.4. We already updated
the lockfile in !4228, so this is just Cargo.toml changes (which will
prevent the minimal-versions tests failing when we change the code to
rely on the fix).
git-grep -l '^derive-deftly' |xargs perl -i~ -pe 's{\b\Q1.11.3\E\b}{1.11.4}g'
|
| | |
| |
| |
| |
| |
| |
| | |
This can happen if we get an unexpected BEGIN_DIR/RESOLVE too, so we
can't hard-code "BEGIN" in the error message.
Context: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4230#note_3439258,
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This feature-gating has been a source of confusion, and it unnecessarily
complicates the stream message handling flow.
I've previously argued in favour of keeping it, in the spirit of a belt
and braces approach to message validation, but I've been convinced that
in this particular case, the feature-gate is more trouble than it's
worth.
What makes things worse is that the `CircHop::handle_msg()`
function was designed poorly (by yours truly). I plan on refactoring it
at some point, hopefully soon. There is a TODO about this below
its doc comment.
|
| | |
| |
| |
| |
| | |
I find this names confusing. To my mind "is" implies a function
returning `bool`.
|
| | |
| |
| |
| |
| | |
It wouldn't make much sense for one concrete type to be unwrappable
variously as different inner types.
|
| |/
|
|
|
| |
This was always TimeValidityError. And we want to rely on that so we
can do the validity checking more centrally.
|
| | |
|
| |
|
|
|
| |
As suggested in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4222#note_3437129
|
| |
|
|
| |
Applies @opara's suggested rephrasing.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
We need to return the "futures::Stream of Tor streams" from the CREATE
handler, because these need to be handled from `arti-relay`,
as per `doc/dev/notes/relay-streams.md`
This commit is intentionally (slightly) misformatted to make reviewing a
bit easier (the next commit will rustfmt everything).
Part of #2612
|
| |
|
|
|
| |
The inner type is an eyesore, and doesn't really need to be exposed
outside of tor-proto (we might even replace it at some point).
|