| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This was a weird name, and while working in this area it all seemed to
make the docs strange.
Rename it. This is quite invasive!
In theory we could have the macros generate compatibility aliases, but
that seems quite complex.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
I keep not finding it because all the other signatures stuff is in
signatures.rs.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This test case constructs a "netdoc" which consists of one
dir-key-certification item, and parses it using `AuthCertSignatures as
NetdocParseable`. But we're going to split out the parsing trait for
signatures sections, so that's not going to work any more.
This test tests only corner cases of the derived
SignatureItemParseable implementation; but that's unit tested in the
parse2 tests. (Once upon a time there was perhaps manual parsing code
which needed a specific test.)
Remove it.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Improve error messages during channel handshake
See merge request tpo/core/arti!3745
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Will clean this up in the following commit.
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
tor-dirclient: Disallow empty successful responses
See merge request tpo/core/arti!3650
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This reflects that it is expected for an HTTP GET body. It is okay
because it is only used in tor-dirmgr, which only performs GET request
anyways.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This commit fixes the previous check to only fail on empty GET
responses. For this, it introduces a `method` field into
`DirResponse`, which is required to determine the method there.
Doing this is reasonable for an HTTP client, as responses have different
meanings depending on the request method used.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This commit disallows empty responses with a status code 200.
From a pure HTTP level, this is totally valid, but it does not make any
sense in the context of the Tor directory protocol, where an empty
response only makes sense with a 404.
The motivation for this is that a work-in-progress
tor_dirclient::send_request wrapper for tor-dirserver passes the
response into the parse2 multiple function which returns a Vec<T>.
Interfacing code would then always have to check for an empty length and
do respective error handling, which should already fail at an earlier
level (tor-dirclient) instead.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Co-authored-by: Ian Jackson <[email protected]>
|
| | | | | | |
| | | | | |
| | | | | | |
Co-authored-by: Ian Jackson <[email protected]>
|
| |/ / / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The issue concerns `libsqlite3-sys` linking to a native library. Cargo
cannot handle multiple versions/crates linking to the same native
library. This affects both the `tor-dirmgr` and `tor-dirserver` crates,
which depend on `rusqlite`.
Relaxing the version requirement gives downstream projects flexibility so
cargo can select an appropriate `libsqlite3-sys` version without a high
chance of conflicts caused by pinning a specific version.
The proposed supported version range was determined by testing until
encountering a version lacking a feature currently in use (breaking
unchange?).
Regarding testing, the current CI with minimum-version test only
validates the maximum and minimum versions, so breaking changes
introduced between them can pass unnoticed. Tools like
[Cargo-Bounds](https://github.com/vivax3794/cargo_bounds) can help, but
this is out of scope for this MR. Also, supported versions of `rusqlite`
for `tor-dirmgr` and `tor-dirserver` differ, so running tests for the
whole project (same workspace) causes cargo to pick only overlapping
versions, which hides parts of each crate’s supported range.
Referencing #754, after this MR, increasing the maximum version or
decreasing the minimum version of `rusqlite` shouldn't be a breaking
change, but increasing the minimum version could be.
Resolves: #1740
|
| | |_|/ /
|/| | |
| | | |
| | | |
| | | | |
I think we currently have the same security features implemented in
Arti as C tor has.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Contains a small code change as `bare_relocation()` was replaced with
`value_relocation()`.
|
| | | | | |
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | | |
Run cargo update post-release
See merge request tpo/core/arti!3740
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
futures 0.3.32 has deprecated UnboundedReceiver::try_next() in favor of
UnboundedReceiver::try_recv(), but try_recv() was only introduced in
0.3.32, so using it would cause our minimal versions checks to fail
(rightfully so, because our code wouldn't build with futures 0.3.x for x
< 32).
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
The responder always sends an AUTH_CHALLENGE cell.
|
| |/ /
| |
| |
| |
| |
| |
| | |
As far as I know, a responder will always send an AUTH_CHALLENGE cell
since it doesn't yet know if the initiator is a client or relay. The
spec also doesn't have any mention about the AUTH_CHALLENGE being
optional. So we should send it in our tests as well.
|
| | |
| |
| |
| |
| |
| | |
Rename them to respectively sensitive() and not_sensitive().
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This is used when we build an OwnedChanTarget using the builder. Instead
of going identities by identities at the callsite, we can use this
helper to get us a RelayIds builder and set it in the
OwnedChanTargetBuilder.
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
On I/O error, we safely log the peer address that was used that lead to
this error.
Closes #2375
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
To make the code a bit better here. Also, at this commit, the
UnverifiedChannel::finish() and VerifiedChannel::finish() are basically
the exact same.
A refactoring to use a finish() helper would work nicely.
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Every specific types know if the peer is sensitive or not so now the
finish() of each of these channel types builds the right PeerInfo with
MaybeSensitive.
This is passed on the Channel so from that point on, the Channel will
never leak peer data in the logs.
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
And implement Display as well. This is for the upcoming changes to be
able to wrap PeerInfo into a MaybeSensitive<> container which can be
logged safely hence the Display.
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| | |
This is meant to be like MaybeRedacted but for the Sensitive<>
container.
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| | |
This required to implement Display for PtTarget.
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| | |
Only the R2R channel that the PeerAddr becomes unsensitive. The rest, we
keep it sensitive as it can be a client or a client's guard/bridge.
Signed-off-by: David Goulet <[email protected]>
|
| |\ \
| | |
| | |
| | |
| | | |
tor-proto: rename 'SLOG'/'CLOG' and related code
See merge request tpo/core/arti!3732
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Version bumps for 2.1.0
See merge request tpo/core/arti!3733
|