| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
These helpers seem potentially broadly useful, and only really
discoverable if they're here.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This includes the ability to generate a seed that does not share a head
with the previously used seed, which is generally what we want to do.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
I'm not particularly happy with the code that does the actual writing
out of the pow-params line, in particular the error handling there seems
very verbose. However, I don't know of a better way to structure it
given that APIs I'm working with.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Fixes: #1691
|
| |/ / / /
| | | |
| | | |
| | | | |
This currently is not implemented.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
cargo_audit: Bump rustls to 0.23.18.
See merge request tpo/core/arti!2641
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
rustls 0.23.13 introduced a bug that causes `Acceptor::accept` to panic
if the client hello is fragmented (see [RUSTSEC-2024-0399]).
We don't currently use `rustls::server::Acceptor::accept()` anywhere in
arti (that I know of, at least), so I don't believe we're affected.
[RUSTSEC-2024-0399]: https://rustsec.org/advisories/RUSTSEC-2024-0399
|
| |\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | | |
tor-chanmgr: change `RequestCancelled` retry from `Never` to `Immediate`
See merge request tpo/core/arti!2640
|
| | | | | | |
|
| |/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
If the channel request was cancelled, we should be able to retry
immediately. Additionally, the `kind()` of `RequestCancelled` is
`TransientFailure`, and I don't think it make sense for a transient
error to return a `retry_time()` of `Never`.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Fix clippy errors
See merge request tpo/core/arti!2639
|
| | | | | | |
|
| | | | | | |
|
| |/ / / / |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
tor-keymgr: Remove dead code
See merge request tpo/core/arti!2638
|
| | | | | |
| | | | |
| | | | |
| | | | | |
This doesn't seem to be needed anymore.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Otherwise, we get a dead code warning when the `ctor-keystore` feature
is disabled.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The fields are never read but need to be present in order for the
dummy `KeyMgrBuilder` to have the same interface as the real one.
(We could of course manually implement the builder, or let the dummy
`KeyMgrBuilder` impl diverge from the real one, but for now let's leave
this as-is and simply mark the fields as unused).
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We no longer have any dummy keymgr operations that return an error,
so this error type is unused.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
This is not used anywhere (or exported publicly).
|
| |\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | | |
Begin implementation work on RPC connect points
See merge request tpo/core/arti!2629
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
("Server support" here means binding to a socket and reading a
cookie file.)
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
("Client support" here means connecting to a socket and reading a
cookie file.)
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
In particular, we only allow binding/connecting to localhost,
and we only support None auth for Unix connections.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
The cookie authentication protocol will need these.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
(Cookie authentication is described in rpc-cookie-sketch.md)
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
While doing so, tidy up the errors that we detect when parsing
a connect point, so that we can differentiate ones that indicate an
unsupported connect-point type.
This means that fewer types now implement Deserialize;
that's probably a good thing.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
See doc/dev/rpc-book/src/rpc-connect-sketch.md for details.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
We'll need this for implementing the connect point logic.
|
| |/ / / / |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
tor-config-path: refactor to support a `CfgPathResolver`
See merge request tpo/core/arti!2615
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Rather than using `arti_client::config::path_resolver()`, third-party
code can get the path resolver using `TorClientConfig`s
`AsRef<CfgPathResolver>` impl instead.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Also updated to use the `PATH_RESOLVER` resolver.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is a big change across multiple crates since there isn't a good way
to break it up.
This changes the signature of `CfgPath::path` to:
```
pub fn path(&self, path_resolver: &CfgPathResolver) -> Result<PathBuf, CfgPathError> {
```
Making this change means that our global `CfgPathResolver` needs to be
stored in the 'arti-client' library instead of `tor-config-path`, and
must be passed through to anything that calls `path` to expand the
variables.
|
