| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
Since config-rs has a bug breaking its support for nested arrays
(see discussion at !1640), we're temporarily changing the format
to a single string with a "=>" in the middle.
I've opened #1058 to put things back as they were once config-rs is
fixed.
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
Closes #939
|
| | |
|
| |
|
|
|
|
|
| |
This lets us provide less information in our logs: in particular, it
lets us avoid logging with microsecond precision.
Closes #551.
|
| |
|
|
| |
As per IRC discussion, re lack of Vanguards.
|
| |
|
|
|
|
|
| |
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 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 precisely the text from the original version of !744.
There is no implementation yet, so we must add a entry to the
exception list in the tests.
|
| |
|
|
|
|
|
| |
This commit largely follows the example for resolve_alternative_specs.
The difference is that there are two fields, so we use a macro to
avoid recapitulating the field names.
|
| |
|
|
|
| |
Previously we logged at "debug", but that's not meant to
user-facing.
|
| |
|
|
|
|
| |
This can be overridden with `application.allow_running_as_root`.
Part of #523.
|
| |
|
|
|
| |
Nothing actually reads this yet, and we also want a client-global
default for padding.
|
| |
|
|
|
| |
This commit is just the necessary plumbing. The config is currently
empty. We'll add something to it, for padding control, later.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is a compile-time feature with an associated configuration
flag, both enabled by default.
When it's turned on, hardening prevents the arti process from
dumping core or being attached to by low-privileged processes.
(This is a defense-in-depth measure, not an absolute way to prevent
attacks. For more information, see
[`secmem_proc`](https://docs.rs/secmem-proc/0.1.1/secmem_proc/).)
Closes #364.
|
| |
|
|
| |
Closes #503.
|
| |
|
|
| |
(This doesn't do anything yet.)
|
| |
|
|
|
| |
This allows us to add the proper default example to the arti example
config file.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Now the validated configuration will never be `Some(0)`, even if that
is what was written in the config file. The arti CLI parser can still
produce this, so we don't touch the code that actually uses this.
(Without the canonicalisation the default builder produces `None` for
the `dns_port`, but the example would produce `Some(0)`, which is
semantically identical but fails the test.)
See https://gitlab.torproject.org/tpo/core/arti/-/issues/488 for some
background.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Canonicalise the `logging.journald` setting in the validated
configuration. Now it will never be `Some("")`, even if that is what
was written in the config file.
This allows us to write `journald = ""` in the example configuration.
(Without the canonicalisation the default builder produces `None` and
the example would produce `Some("")`, which are semantically identical
but fail the test.)
See https://gitlab.torproject.org/tpo/core/arti/-/issues/488 for some
background.
|
| |
|
|
|
| |
These weren't previously discussed. It's not practical or useful to
show the actual default values here.
|
| |
|
|
| |
Found by my forthcoming test.
|
| |
|
|
|
| |
This makes the config default parser see just "[ ]", an empty list,
which is indeed the default.
|
| |
|
|
|
|
| |
This change requires a little refactoring of TorClientBuilder: now,
instead of enabling or disabling mistrust, it enables or disables
the decision to _override_ the mistrust in the config.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
We expect that a user may copy this file and uses it as a starting
point for their own configuration.
When they do that, we don't want them to freeze the default config in
time. Instead, we can expect them to uncomment settings they wish to
change. Then when they upgrade arti, *other* settings will get the
new defaults, which I think is right.
|
| |
|
|
|
|
|
|
| |
Now,
git-grep '^#[^ ]' crates/arti/src/arti-example-config.toml
has no ouptut.
This prepares us for the next commit.
|
|
|
The defaults are built into the code. This is a doc-commented example
file, not the primary specification of what the defaults are.
|