| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
This panics on error, and we're fine with a panic on misbehavior in
tests.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 :-).
|
| |
|
|
|
| |
Maybe this will want to be in tor-error or something but put it here
for now.
|
| |
|
|
|
|
|
|
| |
This test will start to fail if you compile without bridge support,
because we'll start rejecting the test configurations with bridges
specified.
We'll add a proper test for this later.
|
| |
|
|
|
| |
It looks like, despite a few false starts, they've got this warning
right; there weren't any false positives.
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/823#note_2854365
|
| |
|
|
|
|
| |
If there are subkeys which are covered by also expected_missing
superkeys, delete them, since we expect the superkey to be missing, so
the subkey won't show up.
|
| | |
|
| |
|
|
| |
Giving this a name will allow us to refer to it docs in a moment.
|
| |
|
|
|
| |
This allow is also present in the standard lint block at the start of
the test inline module.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This demonstrates that:
* !bridge-client: uncommenting nondefault bridge config generates
urecognized config key warnings (but the config is still accepted)(
* bridge-client, !pt-client: uncommenting nondefault bridges generates
error due to attempting to use a PT. If that's filtered out,
everything is fine.
* pt-client: Everything is good (as before).
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* Introduce filter_examples and resolve_examples helpers,
which will become more complex in a moment.
* Move the API test into a { } block to minimise subsequent diff.
It's going to become conditional.
* In subsequent comparisons, use the parsed version, since
the API built one might not exist.
No overall functional change.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
Section headings appear uncommented in the file, so if we have a
whole section which is completely unrecognized (ie, an entry with no
`.`, it will be spotted when we parse the not-uncommented file too.
Right now there aren't any but there will be in a moment.
|
| | |
|
| |
|
|
| |
It turns out that we will need these even for uncommented parsing.
|
| |
|
|
| |
I had a failure that was confusing to me, and I wrote it...
|
| |
|
|
|
|
|
| |
This lint exists for perf reasons, and this is rarely relevant in
tests.
Using double quoted str is generally cognitively less burdensome.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch changes our `default_config()` test in `arti/src/cfg.rs` such
that we can define a number of known unrecognized options on different
platforms.
We mark the two keys "storage.permissions.trust_group" and
"storage.permissions.trust_user" as unknown on the Windows platform as
such features is not available using the ordinary Unix UID concept.
This patch also publicly exposes the `tor_config::load::DisfavouredKey`
and `tor_config::load::PathEntry` types and marks them as
non-exhaustive.
See: tpo/core/arti#450.
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
This will allow us to handle new kinds of warnigns etc.
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
arti: Do not allow running as root.
See merge request tpo/core/arti!688
|
| | |
| |
| |
| |
| |
| | |
This can be overridden with `application.allow_running_as_root`.
Part of #523.
|
| | |
| |
| |
| |
| | |
Mostly cribbed from
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/684#note_2829937
|
| | | |
|
| |/
|
|
| |
The defaults are now
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
Prompted by review
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/589#note_2813596
|
| |
|
|
| |
It contains only sections, but we want to detect when that is a problem!
|
| |
|
|
| |
We're going to call this new closure another time.
|
| |
|
|
| |
This is the final piece of #457.
|
