| Commit message (Collapse) | Author | Age | Files | Lines |
| |\
| |
| |
| |
| | |
Encapsulate usage of config-rs inside tor-config.
See merge request tpo/core/arti!2040
|
| | |
| |
| |
| | |
This will let us replace Config with something better.
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
| |
The RpcConfig struct is only used if feature rpc is selected.
|
| |
|
|
|
| |
The local name binding for tor_config::define_list_builder_accessors is
only needed if feature onion-service-service is selected.
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
Give an error when user configured onion services with no support.
Closes #1184
See merge request tpo/core/arti!1885
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We do this by adding a stub config and config builder type, whose
only purpose is to generate an error if anything is deserialized
into it.
(If this turns out not to be the best pattern, we can change it
later, since this is all internal to the `arti` crate.)
Closes #1184.
|
| |/
|
|
|
|
|
|
| |
I'm taking this out for now since we don't have support for actually
making these addresses work, and the current behavior will just
ignore connections silently.
Closes #1245
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
The most logical way to do this was to change the "List" type
to a HashMap, and add a build function to the ListBuilder.
This change additionally renames:
OnionServiceProxyConfig{List=>Map}
NamedProxyMap => ProxyBuilderMap
(We now have two kinds of map, and this name change will clarify the
distinction.)
|
| |
|
|
|
|
|
| |
IIUC, there will never be a Some(InNew) entry here, since we will
never have an onion service be configured by default. Instead we
test this kind of configuration by having commented-out options that
we uncomment as needed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
There is a TODO HSS for this. Fixes cargo check --workspace --all-targets
producing
warning: unused variable: `result`
--> crates/arti/src/cfg.rs:1060:13
|
1060 | let result = file.resolve::<(TorClientConfig, ArtiConfig)>();
| ^^^^^^ help: if this is intentional, prefix it with an underscore: `_result`
|
= note: `#[warn(unused_variables)]` on by default
|
| |
|
|
|
|
|
|
|
|
|
| |
This reverts commit 21605d2c9e601c3a5099bfd8d8c887cbb3b36c0a.
We're doing this because we wanted the configuration of proxy rules
to be a 2-tuple, as in `[ "22", "127.0.0.1:22" ]`. But `config`
couldn't handle that before, so we temporarily changed it to
a string, as in "22 => 127.0.0.1:22".
Closes #1058.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
It still matches the start pattern in the same way, but it takes the
_next_ match of the end pattern after the start pattern, and it
allows the end pattern to be absent.
This will make the bridge tests a little more robust, and let the
onion service tests stop saying BEGIN and END.
|
| |
|
|
|
|
|
| |
The problem here is that, for some reason, the proxy_rule
configuration doesn't actually work. I suspect a bug in
Flatten, since the same configuration works fine if you pass
it to the hsrproxy config directly.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
There are no tests for parsing it yet.
|
| |
|
|
|
| |
There's a complaint (seen in a CI build log) about over-eager iterator
item cloning. This is a perf complaint and not very relevant in tests.
|
| | |
|
| | |
|
| |
|
|
| |
Closes #939
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This lets us provide less information in our logs: in particular, it
lets us avoid logging with microsecond precision.
Closes #551.
|
| |
|
|
|
| |
This moves `storage.keystore_dir` to a separate `declare_exceptions`
block and explains why we have this exception.
|
| |
|
|
|
|
| |
Let's remove this until we figure out how the config should behave when
the `keymgr` feature is disabled (should it accept or reject
`keystore_dir = true`?)
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
It's used for declarations only, and they should all be here.
|
| |
|
|
|
|
| |
As per discussion in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1320#note_2916689
and IRC followup.
|
| |
|
|
|
|
|
| |
I think these should go in `[circuit_timing]`. That section already
has some retry parameters, so is not strictly *timing*.
This is not honoured yet.
|
| |
|
|
|
|
|
| |
We put this in `[address_filter]`.
The interaction with the corresponding stream preference is a bit
complicated. We must turn the stream pref into a `BoolOrAuto`.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was super confusing and fragile. Amongst the problems:
* Information about exceptional config keys was spread across a
number of places, manipulated in ad-hoc ways (conditional Vec
appends, etc).
* As a consequence, each exceptional table has confusing and unclear
semantics.
* It doesn't deal well with the way that cargo sometimes enables
features for dependency crates even if arti itself wouldn't demand
them; this can lead to sub-crates supporting config keys when the
tests in arti don't expect them to, causing spurious test failures.
Fix this:
* Introduce a new, systematic, way of writing information about
configuration keys that need some kind of special handling.
* Use this new approach in *both* sets of "thorough" config tests.
* Be more relaxed about deprecated keys. We don't want to tightly
couple this to absence in the supported file, I think.
* Understand more clearly the concept of keys of which we don't know,
in the current build config, whether the code is expected to
accept them.
I have tested this locally with:
for p in '-p arti' '--workspace'; do for f in '--no-default-features --features=tokio,native-tls' '--all-features' ''; do nailing-cargo test $p $f; done; done
|
| |
|
|
|
|
| |
We *do* have a thing that works like this.
It's fragile and confusing and that's what I'm about to fix.
|
| |
|
|
|
| |
Bring the exciting tests together, and move some more normal tests out
of the middle.
|