| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Closes #988
|
| | |
|
| | |
|
| |
|
|
| |
As demanded by rustfmt
|
| |
|
|
| |
This complements the new `check_bridge_pt` test.
|
| |
|
|
| |
This is a bugfix. Perhaps it is a security fix?
|
| | |
|
| |
|
|
|
|
|
| |
The `experimental-api` was only meant to apply to the use of the
unstable `ArtiNativeKeystoreConfig` in the Arti config.
`experimental-api` was _not_ supposed to be used for enabling/disabling
the keystore (that's what the `enabled` flag is for).
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This tries to flesh out some of the details for users who may be new
to bridges and PTs.
Closes #706.
|
| | |
|
| |\
| |
| |
| |
| | |
arti-client: Add keystore_dir to StorageConfig.
See merge request tpo/core/arti!1312
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Part of #891
|
| | | |
|
| |/
|
|
| |
As per IRC discussion, re lack of Vanguards.
|
| |
|
|
|
| |
Invent a trait a la circmgr config for the hs client connector config.
Plumb a suitable value all the way through to the code that will use it.
|
| |
|
|
|
|
|
| |
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`.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One of the tests run as part of `cargo test -p arti-client` fails
because the `pt-client` feature is not enabled by default:
```
failures:
---- src/config.rs - config::BridgesConfig (line 221) stdout ----
error[E0432]: unresolved import `arti_client::config::pt`
--> src/config.rs:225:26
|
7 | use arti_client::config::pt::ManagedTransportConfigBuilder;
| ^^ could not find `pt` in `config`
error[E0599]: no method named `bridges` found for mutable reference `&mut BridgesConfigBuilder` in the current scope
--> src/config.rs:233:19
|
15 | builder.bridges().bridges().push(bridge_1);
| ^^^^^^^ private field, not a method
error[E0599]: no function or associated item named `default` found for struct `BridgeConfigBuilder` in the current scope
--> src/config.rs:236:48
|
18 | let mut bridge2_builder = BridgeConfigBuilder::default();
| ^^^^^^^ function or associated item not found in `BridgeConfigBuilder`
error[E0599]: no method named `bridges` found for mutable reference `&mut BridgesConfigBuilder` in the current scope
--> src/config.rs:247:19
|
29 | builder.bridges().bridges().push(bridge2_builder);
| ^^^^^^^ private field, not a method
error[E0599]: no method named `transports` found for mutable reference `&mut BridgesConfigBuilder` in the current scope
--> src/config.rs:255:19
|
37 | builder.bridges().transports().push(transport);
| ^^^^^^^^^^ method not found in `&mut BridgesConfigBuilder`
error: aborting due to 5 previous errors
Some errors have detailed explanations: E0432, E0599.
For more information about an error, try `rustc --explain E0432`.
Couldn't compile the test.
failures:
src/config.rs - config::BridgesConfig (line 221)
test result: FAILED. 5 passed; 1 failed; 3 ignored; 0 measured; 0 filtered out; finished in 2.10s
```
This disables the `BridgesConfig` doc test if the `pt-client` feature is not enabled.
Closes #843
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| |
|
|
| |
Closes #791
|
| |
|
|
|
|
|
| |
Without this there's no convenient way to add a transport without
messing with serde/toml.
Found while working on #791
|
| |
|
|
|
| |
This panics on error, and we're fine with a panic on misbehavior in
tests.
|
| |
|
|
|
| |
This is precisely the result of running the rune in
maint/adhoc-add-lint-blocks.
|
| |
|
|
|
| |
Since apparently it was possible to write all the other code without
moving it.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
If support is available at compile-time, then we construct a PtMgr
and register it with the ChanMgr. We keep a handle to it ourself so
that we can reconfigure it as needed.
Closes #659.
|
| |\
| |
| |
| |
| | |
arti-client, tor-config: Remove stability warning from top-level docs
See merge request tpo/core/arti!878
|
| | |
| |
| |
| |
| |
| |
| | |
Ticket #285 is closed and most of this is stable now we think.
(There are still a couple of stability warnings for specific types in
tor-config, which aren't exposed at the arti-client level.)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We now parse the `bridges.enabled` BoolOrAuto, and the
`bridges.bridges` list.
The `bridges.bridges` list is Vec<()> in the builder, and Vec<Void> in
the built config. Ie, it is simply a count, and vanishes in the built
config.
But this count triggers us to try to call build(), to try to parse
bridges, and to try to set and honour the enablement boolean.
The result is that the type system now ensures that if bridges are
disabled, but specified (either by listing them in the config, or
writing `enabled=true`), we inevitably try to insist that we have a
non-empty Vec<Void>, which is of course impossible.
There will be a test case too for those who think this too abstract a
way to guarantee this property :-).
|
| |/
|
|
| |
By changing MultilineListBuilder.
|
| |
|
|
|
|
|
| |
This brings the draft configuration mechanisms in tor-ptmgr in line with
the config in other crates, using builders. It also plumbs the config
type through into the main `arti-client` config, and adds some example
lines to `arti-example-config.toml`.
|
| | |
|
| |
|
|
| |
This is the validation which is called for by the documentation.
|
| |
|
|
|
| |
It doesn't seem to me like it makes sense to provide the backward
compatibility here.
|
| |
|
|
| |
Fixes #599
|
| | |
|
