| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |\
| |
| |
| |
| | |
Resolve a couple of new lints with Rust 1.68
See merge request tpo/core/arti!1062
|
| | |
| |
| |
| |
| | |
Apparently 1.68 now warns when you call into_iter() on something
that's already an iterator. Fair enough. Let's stop doing that.
|
| | |
| |
| |
| |
| |
| |
| | |
The derive_hash_xor_eq lint was renamed in 1.68, but we can't use
it under its new name, since we still need to support back to 1.60.
Instead, we suppress the warning about the lint being renamed.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
We have a theory about how this ought to work, so it's noit an API
usage error - it's an unimplemented feature.
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1060#note_2884757
|
| | |
| |
| |
| |
| |
| | |
Reject them both for .onion and for "exit" hostnames
This prevents a `Host` from having an invalid hostname in it.
|
| | |
| |
| |
| |
| | |
Reported in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1060#note_2884755
|
| | |
| |
| |
| |
| | |
Prompted by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1060#note_2884754
|
| | |
| |
| |
| | |
And add some clarity and todos about address errors.
|
| | |
| |
| |
| | |
Provide an explicit From impl isntead.
|
| | |
| |
| |
| | |
This error is not great.
|
| | |
| |
| |
| |
| |
| |
| | |
Now, a Host has a separate variant for `.onion` which is always used,
even when HS is disabled.
Currently it ends in a todo!.
|
| | |
| |
| |
| | |
This is more comprehensible, and will be more convenient.
|
| |/
|
|
|
| |
write! is less good because the `{}` overwrites stuff like "did the
caller ask for padding".
|
| |\
| |
| |
| |
| | |
tor-proto: send an outbound meta/control-message and expect similar messages in return.
See merge request tpo/core/arti!1051
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
(I found "user request" in one place, and fixed that. I am not
currently going to try to unify "control message" and "meta message"
since both terms are misleading and we already have TODOs to try to
merge them into a third better term.)
|
| | |
| |
| |
| |
| | |
This way we don't need to worry about race conditions that happen if
the caller thinks that the handler is installed before it really is.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This new function combines "sending a message" and "accepting
replies in a stream" into a single call, so that there is no gap
between when the message is sent and the replies are available.
There are a number of compromises here, in order to avoid API
proliferation. I've tried to contain them as best I can.
See comments for additional design discussion.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Now, the MetaCellHandler is responsible for consuming the messages
it gets, and reporting status to whatever task is waiting for a
status message.
Additionally, the MetaCellHandler can decide to remain installed or
shut down the circuit after a successful message. (Previously, it
could only uninstall itself on success and kill the circuit on
failure.)
These changes will enable MetaCellHandlers to be used as the basis
for handling more kinds of message.
(There is some moved and reformatted code here; you may want to
review it with `git {diff or show} --color-moved -b`.)
|
| | | |
|
| | | |
|
| |\ \
| |/
|/|
| |
| | |
Introduce and use ends_with_ignore_ascii_case
See merge request tpo/core/arti!1058
|
| | |
| |
| |
| |
| | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1056#note_2884428
|
| |\ \
| | |
| | |
| | |
| | | |
tor-cell: Add code for the payload of an hs-ntor handshake.
See merge request tpo/core/arti!1052
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
(This is the encrypted information inside the INTRODUCE2 cell; it's
used by the client to tell the service where to find its rendezvous
point.)
|
| | | | |
|
| |\ \ \
| |_|/
|/| |
| | |
| | | |
arti-client: Do not send resolve requests for IP addrs to exits
See merge request tpo/core/arti!1057
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When I was trying to add HS support to these layers, I found I could
add a new variant to the `Host` enum but everything would still
compile even though I hadn't written the necessary implementation!
This method is a liability: when using it, one inevitably writes such
latent bugs.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Doing so doesn't seem like a good idea. It might even be some kind of
leak?
Found because I added a variant to `address::Host` for hidden
services, and noticed that the resolve code still compiled.
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Use new strip_suffix_ignore_ascii_case
|
| | | | |
|
| | | | |
|
| |/ /
| |
| |
| | |
We're going to want this for cheaply stripping ".onion" from things.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
tor-dirmgr: Don't try to mark consensus usable in a read-only store.
Closes #779
See merge request tpo/core/arti!1055
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Doing this means that any attempt to use a read-only store would
crash as soon as it found that the consensus was usable.
It seems that this bug was introduced at some point doing all the
dirmgr refactors we did over the past year. Perhaps there should be
a test for running with a read-only store.
Fixes #779
|
| |\ \ \
| |/ /
|/| |
| | |
| | | |
tor-bytes: defend against misuse of extract_n().
See merge request tpo/core/arti!1053
|
| | | | |
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, if somebody wrote this code, an attacker could easily
use it to cause an OOM panic:
```
let n = r.take_u64();
let items: Vec<Foo> = r.extract_n(n as usize)?;
```
The first line of defense here is not to write protocols like that:
we don't actually _have_ any 32-bit counters in our protocol
AFAICT.
The second line of defense is to pre-check `n` for reasonableness
before calling `extract_n`.
Here we add a third line of defense: whereas previously we would do
`Vec::with_capacity(n)` in `extract_n`, we now allocate an initial
capacity of `min(n, r.remaining())`. This ensures that the size of
the allocation can't exceed the remaining length of the message,
which (for our cell types at least) should prevent it from
overflowing or running OOM.
|
| |\ \
| | |
| | |
| | |
| | | |
Impl FromStr and Display for HsId, etc.
See merge request tpo/core/arti!1054
|
| | | | |
|