| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Per comments on #1383, we're keeping these methods.
This commit replaces the "TODO" comments with comments explaining
why it's okay that this methods are unused.
Part of #1383.
|
| | |\ \
| | | |
| | | |
| | | |
| | | | |
RPC: Allow SOCKS applications to create streams.
See merge request tpo/core/arti!2143
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The problem was that Rust won't let us say
```
type ConnTarget<R> = Arc<dyn ClientConnectionTarget>;
```
because the R parameter wasn't used.
Previously we solved this by using a macro instead of a type
definition, which is ugly.
I had been thinking previously I would need to declare some kind of
additional wrapper type, and had shrunk from the verbosity. But
@diziet pointed out that I could just use a 2-tuple unconditionally.
It's still not beautiful, but it is less hideous than before.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Document its relation to the method system, and possible future
evolution.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
Also, improve documentation.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
(This is a separate commit to make the branch more readable)
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The application creates these, using a new-stream-handle RPC command,
on an object that can actually create streams.
Then later, the application provides the (global) identity of one of
these objects when it's making a SOCKS connection. This causes the
object to take hold of a `DataStreamCtrl`.
|
| | | |/
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
(These will later become objects that can receive any application
request, once we have HTTP connect.)
For now, Session and TorClient implement this trait;
but soon there will be a new type to hold on to the created
DataStreamCtrl.
There are some XXXXs here, marking code that is too ugly to live.
I should fix it before I merge this branch.
|
| | |/ |
|
| | | |
|
| | |\
| | |
| | |
| | |
| | | |
RPC: Preliminaries for RPC-stream integration
See merge request tpo/core/arti!2140
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Instead, add a trait so that we can hold TorClient<R> and invoke
only the methods on it that we need.
This is a partial revert of 47f012829d3381fd896c6b6f20961fbfe2f40f6d.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
Previously we could only downcast to &dyn Trait,
which is not adequate.
|
| | | |
| | |
| | |
| | |
| | | |
This makes `ObjectRefExt` less necessary, and will let us make it
Arc-only.
|
| | | |
| | |
| | |
| | | |
I think I'm going to add another stream management module here.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This change allows it to hold a TorClient<R> that isn't type-erased.
We'll use this for cases when we need to get the client directly
and call functions on it.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | |\ \
| | | |
| | | |
| | | |
| | | | |
tor-guardmgr: Address some vanguard-related TODOs
See merge request tpo/core/arti!2139
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
I don't think it's all wrong, this was left over from the first draft
implementation.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Previously, `select_vanguard` returned a `NoSuitableRelay` error if
it was unable to select a relay to use as a vanguard.
We now distunguish the "there are no suitable relays in the vanguard
sets" (`NoSuitableRelays`) error case from the "our vanguard sets are
empty" (`BootstrapRequired`) one.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This is about to grow another variant, so I'm moving it to a dedicated
`err` module.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The `match` below it is fine, there's no need to rewrite it.
(I think this TODO is actually dupe of the the TODO above it).
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
I think it's alright to keep it: it gives us the flexibility to extend
it later on, if needed.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This TODO doesn't really need to be implemented: we can test the
`VanguardMgr` just the same without it (`GuardMgrInner` is similar, in
that it doesn't mock the rng).
|
| | | | | |
|
| | | |/ |
|
| | |/
| |
| |
| | |
This is a follow-up from !2131
|
| | |\
| | |
| | |
| | |
| | |
| | |
| | | |
tor-keymgr: Refactor code shared between ArtiNativeKeystore and ArtiEphemeralKeystore
Closes #1362 and #1367
See merge request tpo/core/arti!2131
|
| | | |
| | |
| | |
| | | |
This reverts commit 9ea35caeb1ed23fd029627d04819debc41d85c77.
|
| | | |
| | |
| | |
| | | |
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2131#note_3028014
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This updates the keymgr tests to be slightly more robust.
These tests attach some metadata to each key, such as the "nickname" of
the key (which only exists for testing purposes), whether the key was
auto-generated, and the keystore ID of the keystore from which the key
was retrieved.
Previously, the metadata was encoded in the key "material" itself (the
test "keys" were actually just `String`s with a hacky `EncodableKey`
implementation that abused the "encrypted" variant of `KeypairData`).
This was only possible because we had access to the key internals
(through `SshKeyData::Public`/`SshKeyData::Private`), but since the
internals are inaccessible now, the tests need to be updated.
|