| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
These are my notes and observations about the circuit and channel
reactors. In hindsight, this whole document is just stating the
"obvious"[^1], so I'm not sure if it's going to be useful for anyone
else. Also, since this isn't part of the code docs or tor-proto
crate-level docs, it's very likely to become outdated in the near
future.
At the end of the document, I also wrote a very rough KIST
implementation plan based on the discussion from #1712.
Closes #1747
[^1]: scare quotes because the "obvious" is only obvious after you've
stared at the circ/chan reactors for a while
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Start of host-side onion service PoW support
Closes #1691
See merge request tpo/core/arti!2609
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
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.
|