| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This will be used for the `vanguard.mode` config option. The
`VanguardMode` corresponding to the `"auto"` variant will depend
on whether the `vanguards` feature is enabled: if the feature is
enabled, it is mapped to `VanguardMode::Lite`, and
`VanguardMode::Disabled` otherwise.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We want to export the `VanguardConfig` even if the `vanguards` feature
is disabled (we will need to unconditionally include it in the arti
config).
Note that if `vanguards` are disabled, the `VanguardMode` from the
`VanguardConfig` can only be `Dsiabled`.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is already exported via the `pub mod vanguards` module, so there is
no need to export it from the top-level too. This *is* a breaking change,
but the downstream fix is trivial (and the type should never have been
exported directly from `arti_client::config` in the first place).
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
tor-keymgr: Add script for generating test key files.
See merge request tpo/core/arti!2121
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
The keys generated in this commit are reproducible using the
`maint/keygen-openssh-test/generate` script.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This commit contains a new set of `tor-keymgr/testdata` keys,
generated using ./maint/keygen-openssh-test/generate.sh`.
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2121#note_3025369
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
`tor-keymgr/testdata` contains a bunch of OpenSSH keys used for testing.
I meant to share the script I generated them with, but somehow never got
around to it.
Note: the OpenSSH keys generated by this script are going to look
slightly different than the ones that are checked into the repo. This is
because some of those original key files were generated ad-hoc (I
manually modified them a while ago, but I forgot exactly how
|
| | |/ /
|/| |
| | |
| | |
| | |
| | |
| | | |
Related to C-tor MR:
https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/819
Signed-off-by: David Goulet <[email protected]>
|
| |\ \ \
| | |/
| |/|
| | |
| | | |
Tidy up the ChannelSender::poll_ready inherent method
See merge request tpo/core/arti!2171
|
| | | | |
|
| | | |
| | |
| | |
| | | |
This is where it belongs.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
This makes this available for any Sink + Unpin. Which we want because
we're about to wrap our ChannelSender in a Sink wrapper.
It's in the wrong place now; we'll move it in a moment.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This would otherwise shadow the poll_ready method, which is
confusing.
Also this paves the way for making it available for any
Sink + Unpin.
Improve the docs somewhat to explain what this thing actually is.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I think this error was in fact always Error::CircuitClosed because it
came from ChannelClosed.into(). Anyway, we shouldn't squash it.
Now this function has semantics identical to Sink::poll_ready, just a
slightly different signature.
|
| | | |
| | |
| | |
| | | |
Make it clear we're discarding `()`, not an actual value.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We're going to change this function, but first we are going to make
its behaviour identical to Sink::poll_ready.
This avoids open-coding the call to poll_read on cell_tx.
The error handling is still strange. We'll fix that in a moment.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This test verifies that when we invoke the code to close a stream,
an END message is actually sent.
The test comes in two versions:
* `drop_stream` closes the stream by dropping it. It currently
passes on main.
* `close_stream` closes the stream by running `AsyncWriteExt::close`
on the writer. It is a regression test for #1368. It currently
fails on main.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
In particular, clarify that dropping the DataWriter on its own does
nothing unless the DataReader is also dropped.
Related to #1368.
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously we had a bug where `<DataWriter as AsyncWrite>::close`
(or `shutdown` in tokio-land) would not actually have any effect.
It _would_ drop the `StreamTarget` held by the `DataWriter`, but
since the `DataReader` also held a `StreamTarget`, the
MPSC channel would not get closed, and the circuit reactor would
not realize that the stream wanted to shut down.
Now we use `mpsc::Sender::close_channel` to make our closes
effectual.
Closes #1368.
Additionally, we fix a bug where `poll_close()` never actually did
anything if the buffer had nothing in it when it was called.
Previously, `poll_flush_impl()` would exit immediately if it had no
data to flush. That isn't what we want when we are closing!
|
| |\ \
| | |
| | |
| | |
| | | |
Proto: Refactor Channel to always be Arc.
See merge request tpo/core/arti!2163
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously ChannelDetails had a double duty: It held elements shared
among the clones of a Channel, and it also held elements shared
between the Channel and the Reactor. But now that Channel doesn't
have to implement Clone, we can more the non-Reactor elements into
Channel itself.
This change may improve cache locality a bit, and should make it a
little easier to follow the channel code.
I've also moved unique_id out of ChannelDetails into Channel _and_
Reactor: it is small, immutable, and used all the time in logging.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously, Channel was a type that you could Clone that implicitly
its state. Now, Channel always appears as an Arc<Channel>.
This change has several benefits:
* It makes the relationship between Channel struct and the
underlying channel more clear.
* It enables Channel to participate in the RPC system,
where everything has to be an Arc<.>
* It enables us to have a Weak<Channel>, if we ever want to.
* It will let us move various members out of ChannelDetails.
We did this change a while ago with ClientCirc.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This serves three purposes:
* It removes the 'send a cell' method from the channel's public
API. Nothing outside of tor-proto should have to use this.
* It paves the way for giving each circuit a separate handle onto
the channel's send functionality. This will eventually let
the channel multiplex among circuits more intelligently.
* It prepares for the next commit, which will make Channel itself
universally Arc<.>ed.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
For all mutable shared state, we ought to know which part of the
program sets it, which part of the program reads it, and why.
|
| |/ /
| |
| |
| |
| |
| | |
(This isn't a bugfix, but it helps avoid the appearance of a
function calling itself. This _would_ become a bug if we imported
the wrong trait into scope here.)
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Allow RPC methods with non-serializable types
Closes #1403
See merge request tpo/core/arti!2152
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
We need to do this so that we can actually invoke RPC functions
from one another.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
Now that Method::Error exists, we can downcast Any to the actual
function's return type.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is needed so that we can cast special methods' return types
properly.
I wish I could make this optional, but Rust doesn't allow
defaulting an associated type.
|
| | | |
| | |
| | |
| | | |
A @special invoker does not get an RPC entry.
|
| | | |
| | |
| | |
| | |
| | | |
Now Methods can return anything; and only if their outputs are
Serialize will they implement RpcInvocable.
|
| | | |
| | |
| | |
| | |
| | | |
RpcInvocable will only be implemented on types whose output
can be serialized.
|
| | | |
| | |
| | |
| | | |
This is part of work on #1403.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This will allow us to create dispatchable methods that are only
invoked from inside the arti code, and are not themselves
serializable.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
tor-circmgr: Replace STUB/STUB+ terminology with SHORT/EXTENDED.
Closes #1339
See merge request tpo/core/arti!2161
|