| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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".
|
| |\
| |
| |
| |
| | |
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
|
| |\ \
| |/
|/|
| |
| | |
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
|
| |
|
|
| |
Fixes #756
|
| |
|
|
|
| |
This panics on error, and we're fine with a panic on misbehavior in
tests.
|
| |
|
|
| |
Fortunately, it adds very little to the arti-client API surface.
|
| |
|
|
|
| |
This is precisely the result of running the rune in
maint/adhoc-add-lint-blocks.
|
| |
|
|
|
| |
It looks like, despite a few false starts, they've got this warning
right; there weren't any false positives.
|
| |\
| |
| |
| |
| | |
Use hostname-validator crate for hostname validation
See merge request tpo/core/arti!739
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
| |
This is closer to what we described in Errors.md.
Also, remove the (sometimes private) Result alias: it was only used in
one or two places, and never exposed in public.
|
| |
|
|
| |
We are going to make the top-level Error type conditionally hidden.
|
| | |
|
| |
|
|
|
|
| |
We _do_ reject bad hostnames: just not where I once thought we might.
We need to decide if the current behavior is what we want (and I think
it is, probably?).
|
| |
|
|
| |
This makes sure that we're checking for a nonzero port in all cases.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most of the structs in `arti-client` have example code now, to give a
clearer idea of how they're used.
Annoyingly, a lot of the types exposed in `arti-client` are actually
re-exports, which makes documentation a bit harder: example code that
references other parts of `arti-client` can't actually be run as a
doctest, since the crate it's in is a dependency of `arti-client`.
We might be able to fix this in future by doing the documentation in
`arti-client` itself, but rustdoc seems to have some weird behaviours
there that need to be investigated first (for example, it seems to merge
the re-export and original documentation, and also put the re-export
documentation on the `impl` block for some reason).
For now, though, this commit just writes the docs from the point of view
of an `arti-client` consumer, removing notes specific to the crate in
which they're defined. It's not ideal, but at least the end user
experience is decent.
|
| | |
|
| | |
|
|
|
Solves a name conflict with the existing tor_client create.
Closes #130.
|
