| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
arti: Warning when opentelemetry config is set but not build with feature
Closes #2247
See merge request tpo/core/arti!3458
|
| | | | | |
| | | | |
| | | | |
| | | | | |
It seems this config is for tokio-console and not the RPC.
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Validate Host header for non-CONNECT requests to HTTP CONNECT port
See merge request tpo/core/arti!3429
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This validation makes it harder for an adversarial webpage to probe
for the version of arti and its capabilities.
See torspec!437.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
x509: Support generating the keys and certs that relays need for TLS
Closes #2205
See merge request tpo/core/arti!3349
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Although we never need to actually check the signature on the other
party's x509 certificate, A relay does need a certificate and a
private key in order to be a proper TLS server.
In this function, I've added support for making an ersatz P-256
certificate certifying a P-256 key. See the code for info about the
rationale here. (Tor supports this, since it doesn't look at the
key at all: only the TLS layer cares about that.)
native_tls and rustls expect to get their keys and certs in
different forms, so this code provides them.
(Note that we don't expect to use native_tls with relays in the
first place, but it might be useful for lower-level interop
testing.)
Closes #2205.
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This doesn't give precisely the same results as before for leap
years, but that should be okay.
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
retry-error: Stop trying to dedup error messages
See merge request tpo/core/arti!3465
|
| | | | | | | | | |
|
| | | |_|/ / / /
| |/| | | | | |
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Implement a usage-based timeout for strongly isolated circuits (prop368)
Closes #2237
See merge request tpo/core/arti!3430
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
(The only error possible is an internal error from
calling it with a non-long-lived tunnel.)
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
This code uses the algorithm of prop368: When a tunnel is
sufficiently isolated, we want to expire it after it has been
disused for a certain amount of time.
The implementation is a little tricky, since we need to call an
async function on ClientTunnel to look up the disused_since() check.
We don't want to call async functions while holding locks, so
we need to drop the TunnelList lock before we do the disused_since()
calls, and the grab it again.
As part of this change, I've had made expiration functions return
the earliest time at which any tunnel might expire. We can use
this in the future to spawn fewer expiration tasks, and scan the
list of tunnels less often.
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Instead of a series of cutoffs, take an object with a set of
lifetimes.
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
We'll need them to be async so they can call disused_since() on tunnels.
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Part of prop368.
|
| | | |/ / / / /
| |/| | | | |
| | | | | | |
| | | | | | | |
This is part of an implementation for proposal 368.
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
arti: Remove security disclaimer from onion service support
See merge request tpo/core/arti!3464
|
| | | |/ / / / /
| |/| | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
These appear to be old comments. Now that these features are stable, we
consider them safe to use.
|
| |/ / / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
`CircHop::relay_format()` returned the same thing as
`CircHop::relay_cell_format()`.
|
| |\ \ \ \ \ \
| |_|_|/ / /
|/| | | | |
| | | | | |
| | | | | | |
proto: Remove a no longer relevant TODO
See merge request tpo/core/arti!3463
|
| | |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
I think this was addressed by @opara in
eca15143ba80b789382ba7cbe19601d3b98e42c2.
Spotted while refactoring `CircHop`.
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
tor-rtcompat: Use a consistent listen implementation, and set `IPV6_V6ONLY` for listening sockets on `cfg(unix)`
Closes #2246
See merge request tpo/core/arti!3457
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This gives us a consistent `listen()` implementation across runtimes,
and gives us flexibility to customize the bind/listen process for TCP
sockets.
|
| |\ \ \ \ \ \
| |_|_|_|_|/
|/| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
arti/arti-client/tor-hsservice: Support disabling onion services in the config
Closes #2133
See merge request tpo/core/arti!3253
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
We don't need to modify semver files for newly added methods.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Combined with the previous commit, this completes my second attempt at
correctly handling the semver files.
tor-hssservice:
I removed the extra bit at the end of the first line explaining the
semantics of the new return type, since the important part is really
just the fact that the return type changed. The semantics are documented
in the methods themselves.
arti-client:
Same as above, but I also removed the `client` module prefix since the
`client` module isn't actually public, so to external crate users the
broken type is directly in the crate root.
Removed old "used in the public API of this crate" line.
Added lines referring to the 2 breaking changes we re-export from
tor-hsservice.
arti-ureq:
Removed old "used in the public API of this crate" line.
Added lines referencing every breaking change in arti-client. This MIGHT
be wrong, but I think this is correct because we re-export arti-client
as a whole.
Signed-off-by: hashcatHitman <[email protected]>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Second attempt at semver in progress. Based on the feedback from wesley,
it seems neither of these crates had any breaking changes.
Signed-off-by: hashcatHitman <[email protected]>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
If I understand correctly, the breaking changes propagate like this.
Signed-off-by: hashcatHitman <[email protected]>
|
