| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
| |
These are all aimed at figuring out in more detail what's going on
in #2079 and related issues.
|
| |
|
|
| |
Run maint/add_warning
|
| |
|
|
| |
Part of #1885.
|
| |
|
|
| |
This feature has been removed from nightly, in favor of doc_cfg.
|
| |
|
|
| |
This is part of abolishing the use of "ns" to mean "plain".
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
| |
This entirely removes the requirement on ClientCirc.
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| | |
|
| |
|
|
|
| |
These errors are suspicious as hsdir inflation attacks, in the
context of prop360.
|
| |
|
|
| |
(This was previously called a parse error, which isn't right.)
|
| | |
|
| |
|
|
|
|
|
| |
1) It's the last hop that matters, not the first.
2) The last hop could conceivably be virtual, making the source anonymous.
(Though this never happens in Arti today.)
|
| |
|
|
| |
See #2060.
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
Fix clippy warnings from nightly rust
Closes #2009
See merge request tpo/core/arti!3008
|
| | |
| |
| |
| |
| |
| | |
Clippy nightly detects this problem, though earlier clippy verisons
haven't. The common element here is applying unwrap() to the result
from a write!().
|
| |/
|
|
|
|
|
|
| |
This suffix is redundant with "Accept-Encoding",
which all Tor directory caches have supported
since 0.3.1.1-alpha.
See torspec#342.
|
| |
|
|
|
|
|
|
| |
This is messy, because `ClientCirc::{path_ref, n_hops, ..}` become
fallible (we can't unwrap the result, because when a circuit is closed,
its state gets removed from the `TunnelSharedState`, but its
`ClientCirc` handle continues to exist, so any attempt to retrieve the
state will result in an `Err`).
|
| |
|
|
|
|
|
| |
MockSleepProvider and MockSleepRuntime have been declared deprecated
by the docs for some time. We're about to mark them `#[deprecated]`.
This commit has been split out for clarity of review.
|
| | |
|
| |
|
|
|
|
| |
Denies 'mod.rs' files for consistency.
https://rust-lang.github.io/rust-clippy/master/index.html#mod_module_files
|
| |
|
|
|
|
|
|
| |
In 1.83, this warning triggers on many of our crates.
We're thinking of fixing them all, but for now,
we're going to disable the warning.
This is part of #1765.
|
| |
|
|
|
|
| |
The `derive_more` crate broke backward compatibility with this version,
so this change involved quite a few manual fixups.
With luck, they'll keep compatibility for some while in the future.
|
| | |
|
| |
|
|
| |
This commit is automatically generated.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
The HTTP status text is often useful for diagnosing errors. Tor
directory and hsdir caches frequently put useful messages there,
especially when rejecting an uploaded document.
Inspired by #1142.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to RFC 9110:
A user agent SHOULD send Content-Length in a request when the
method defines a meaning for enclosed content and it is not sending
Transfer-Encoding. For example, a user agent normally sends
Content-Length in a POST request even when the value is 0
(indicating empty content). A user agent SHOULD NOT send a
Content-Length header field when the request message does not
contain content and the method semantics do not anticipate such
data.
Part of #1024
|
| |
|
|
|
| |
As per this comment, and preceding discussion
https://gitlab.torproject.org/tpo/core/arti/-/issues/1060#note_2959187
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Since none of these methods were invoked from outside
`tor-dirclient` (except for debugging), and since we have had a fair
amount of churn on what we actually want them to be, it seems like a
good idea to use this trick to hide them. This will let us make
other changes to the actual behavior of Requestable in the future.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Since not everybody has xz and/or zstd, we don't want to admit
whether we support them when we are uploading or downloading an
onion service descriptor. Similarly, if we aren't advertising
support for an encoding, we shouldn't accept it.
Finally, while we're doing this, it made sense to have the ability
to mark requests based on how anonymized they are, and reject (some)
attempts to send those requests over a one-hop circuit.
Closes #1062
|
| | |
|
| |
|
|
|
| |
Not checking whether the response is successful can have unintended
consequences.
|
| | |
|
| | |
|
| | |
|