| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The module is correctly documented as "only available on crate feature
restricted-discovery" without it.
|
| | | | | | |
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Without it, if the `restricted-discovery` feature is compiled out, the
module gets documented as:
```
Non-restricted-discovery (Available on non-crate feature `restricted-discovery`
only)
```
which is inaccurate.
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | | |
Don't require TRANSPORT for PT STATUS messages.
See merge request tpo/core/arti!2307
|
| | | | |
| | | |
| | | |
| | | | |
See: tpo/core/arti#1488.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This patch changes the PT STATUS handler to not require the presence of
the `TRANSPORT` field in the K/V line. This matches current behaviour of
C Tor and was requested by the Anti-censorship Team at an earlier point
to enable STATUS messages to work for situation where it's not transport
specific messages.
To avoid future issues, we simply ignore any required keys right now
even though TYPE is to be expected.
See: tpo/core/torspec#267
See: tpo/core/torspec!63
See: tpo/core/arti#1488
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
shadow test: Add tests for restricted discovery hidden services
See merge request tpo/core/arti!2272
|
| | | | | |
| | | | |
| | | | |
| | | | | |
This helped me debug some shadow test failures.
|
| |\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | | |
rpc-client-core: Always re-encode requests and responses, and preserve unrecognized struct fields.
Closes #1491
See merge request tpo/core/arti!2312
|
| | | | | |
| | | | |
| | | | |
| | | | | |
This enable a `meta` object to have no `updates` field set.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We want to re-encode responses to avoid possible mismatch between
how arti-rpc-client-core parses messages and how the user application
parses messages. (In theory this shouldn't be necessary so long as
arti-rpc-client-core and arti have the same json implementation,
and arti-rpc-client-core is only used for talking to arti.
But those assumptions might change in the future.)
Closes #1491.
We want to preserve fields so that, if Arti adds any new elements
to response or error in the future, and the client knows about them,
they won't be lost simply because arti-rpc-client-core hasn't heard
of them.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
When writing a request, we want to keep any fields that we don't
recognize, in case the application (and arti) know about some
field that we haven't heard of.
|
| | | |/ /
| |/| |
| | | |
| | | | |
(They are about to diverge even further.)
|
| | | | |
| | | |
| | | |
| | | | |
This also adds a test for it.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This rewrites `RestrictedDiscoveryConfig::read_keys` to give
`static_keys` precedence over the keys from `key_dirs`.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
MAX_RESTRICTED_DISCOVERY_CLIENTS.
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2266#note_3051758
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
descriptor.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
The base64ct dependency is now unused in tor-hsservice, so we should
consider removing it at some point.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
We can just used `build_for_arti()` here.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
`BuilderExt` will soon be used in tor-hsservice too (for configuring the
mistrust settings of the client "restricted mode" authorization keys).
|
| | | | |
| | | |
| | | |
| | | | |
Needed because such keys will be stored in the `OnionServiceConfig`.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Restricted discovery mode is initially going to be gated behind the
experimental `restricted-discovery` feature.
Part of #1292
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This also makes the `tests/testcases/hsc/hsc.md` test case a symlink to
`doc/hsc.md`.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This adds a bit more information to `hsc.md`.
Note: `hsc.md` is currently just a test case for the CLI tests. A future
commit promote it to module-level README.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Fix a pair of typos in an ffi comment.
See merge request tpo/core/arti!2310
|
| | |/ / / |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
ffi: Expose errno from errors that have it.
Closes #1501
See merge request tpo/core/arti!2311
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Closes #1501.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
(This is an errno or a GetLastError.)
|
| | |/ / /
| | | |
| | | |
| | | |
| | | | |
This will make error outputs more usable, and will make it possible
to expose OS error codes.
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The help output of the `-c ` option includes some local paths, which can
be quite long on some platforms, spanning over multiple lines. This
causes the CLI tests to fail, because they expect each of the paths from
the `-c` help to fit on a single line.
To fix this, we can use `trycmd`'s `...` to match as many lines as
needed.
Closes #1509
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Have `arti hss onion-name` error if it doesn't print the onion name
See merge request tpo/core/arti!2305
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
There are two error cases where the onion name isn't printed, but
previously returned `Ok(())`.
It now returns an error to exit with a non-zero status code.
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | | |
tor-proto::circuit::StreamMap: Use StreamPollSet
See merge request tpo/core/arti!2285
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We no longer need this. StreamMap now supports handling only one
outgoing message at a time while ensuring no streams starve, so we no
longer ever pull messages out of the map when we're not actually ready
to send them.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* Refactors `StreamMap` to use `StreamPollSet` to manage its receivers
for mpsc streams.
* Extends `StreamMap` to support iterating only over streams that have a
pending outgoing message, and in round-robin order.
* Updates `circuit::reactor::Reactor` to use this functionality. It now
iterates only over streams that have a ready outgoing message, and
only actually "pops" a message that is ready to be sent.
This mildly simplifies the circuit reactor, but more importantly clears
the way to:
* Remove the "outbound queue" of messages that were pulled from stream
channels but that we couldn't send yet due to congestion control.
* Support opportunistic packing when preparing to send a relay message.
(proposal 340).
* Refactor the circuit reactor's `run_once` into futures that we can
`select!` over.
|
| | | | | |
|
| | |/ / |
|
| |/ / |
|