| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
| |
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
|
| | |
|
| |
|
|
|
| |
The referenced ticket is closed and I think the top-level caveats
remaining after !717 are sufficient.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/682#note_2830860
And subsequent IRC discussion.
Having done the work as per review comments, I don't much like the
result. It's quite un-ergonomiuc. If we can't have fs autodetection,
I think syntactic autodetection within sources.rs would be nearly as
nice.
However, I seem to be outvoted. At least the externally visible
functionality (of an arti binary, say) is reasonably ergonomic.
|
| |
|
|
| |
Fixes #474 aka #271
|
| |
|
|
|
|
|
|
|
| |
This gets rid of many Result(). Many parameters are renamed.
Test cases of the now-impossible branch are removed.
Deleting the match from padding_parameters will come in a moment.
I've split off that commit since it has much whitespace noise.
for now, change the error type to Void.
|
| |
|
|
|
| |
This commit is just the necessary plumbing. The config is currently
empty. We'll add something to it, for padding control, later.
|
| |
|
|
| |
Closes #503.
|
| |
|
|
|
|
| |
This name is more accurate because we aren't only dealing with
clock skew here: we're also trying to tolerate the case where the
authorities fail to reach consensus for a while.
|
| |
|
|
|
|
|
|
| |
This logic can now be adjusted via the config object so that it does
its own overriding by looking at the environment as appropriate.
Removing these methods helps simplify the code a bit.
Enabled by #483.
|
| |
|
|
|
|
|
| |
The variable is now handled when building the configuration, and no
longer needs to be special-cased.
Closes #483.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This gets rid of `#[serde(flatten)]` which prevents serde_ignored (and
other kinds of introspection) from working properly.
The price is now that the toplevel has to deal with two configuration
objects.
The Resolvable trait is overkill right now, but is going to do More
Things in a moment. In particular, we need the impl on tuples, so
that the whole config can be processed in one go.
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
| |
This is an approximately minimal revision to get Builder in place;
subsequent commits will clean up the API.
|
| |\
| |
| |
| |
| | |
Abolish arti-config, replacing with tombstone crate
See merge request tpo/core/arti!508
|
| | |
| |
| |
| |
| |
| | |
That's where this definitions is now. This test ought to have been
moved in
Move default_config_file() into arti-client
|
| |/
|
|
|
| |
This deletes many handcoded impls. It also generates lots of impls
that we previously didn't have.
|
| |\
| |
| |
| |
| | |
impl_standard_builder followup
See merge request tpo/core/arti!505
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I have Plans for this macro. In particular:
* I have a wip branch which tests that the Builder can be
deserialised from an empty config (ie, that config reading
of a config with a blank section for this item works).
* I think we should autogenerate $Config::builder(),
and promote that, rather than $ConfigBuilder::default().
This macro could do that.
|
| | |
| |
| |
| |
| |
| |
| | |
This macro is kind of derive-y. Also it has a test in it, and failing
to call it could allow bugs to exist, as well as missing bits of API.
Putting it next to the structs makes it easy to see that it's actually
been called.
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
Teach DirMgr to use slightly untimely directories
Closes #467 and #412
See merge request tpo/core/arti!500
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This new section describes how much variance we accept when it comes
to expired and not-yet-valid directory documents. (Currently, the
only ones where this matters for are consensus documents and
authority certificates.) A document that is invalid by no more than
these tolerances is not _live_, but it can still be used.
These tolerances serve two purposes:
* First, they allow clients to run with a little more clock skew
than they would tolerate otherwise.
* Second, they allow clients to survive the situation where the
authorities are unable to reach a consensus for a day or two.
Compare with Tor's REASONABLY_LIVE_TIME and NETWORKSTATUS_ALLOW_SKEW
constants; also compare with proposal 212.
Closes #412.
|
| |\ \
| | |
| | |
| | |
| | | |
Provide and use macro for impl Derive via Builder
See merge request tpo/core/arti!499
|
| | | | |
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| | |
Discovered by a test case in my local tree. The test case was
macro-generated by an extension of impl_standard_builder (which
macro istself currently awaiting review, arti!499)
Have also sent an MR to update the upstream docs
https://github.com/jean-airoldie/humantime-serde/pull/8
|
| |/
|
|
| |
This will let other embedders use it.
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I'm doing this per discussion, so that we can have it be part of the
TorConfig later on, and not break stuff as we change the Mistrust
API to have a builder.
This change, unfortunately, results in a little more internal
complexity and duplicated code in arti and arti-client. I've marked
those points with TODOs.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
This is derived from the environment, not the configuration file: We
might not want to trust the configuration file until we've decided
whether we like its permissions.
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Builders additionally derive: Debug, Serialize, Deserialize.
* Validated structs no longer derive: Serialize, Deserialize
and all related attributes deleted.
* As a consequence, all the `#[serde(deny_unknown_fields)]`
are gone. That means that right now unknown fields are totally
ignored. This is good for compatibility but poor for useability.
Doing something better here is arti#417, in progress.
* As a consequence, delete tor_dirmgr::retry::default_parallelism.
(The default value was already duplicated into a builder attr.)
|
| |
|
|
|
|
|
| |
And drop the ad-hoc orport() method. This brings FallbackDir's
orports field in line with our list builder API.
The general semver note in "configuation" seems to cover most of this.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new API is (roughly) as discussed in
https://gitlab.torproject.org/tpo/core/arti/-/issues/451
This is quite a large commit and it is not convenient to split it up.
It contains the following changes:
* Redo the list builder and accessor macros implemnetation,
including docs and tests.
* Change uses of define_list_config_builder. In each case:
- Move the docs about the default value to the containing field.
- Remove the other docs (which were just recapitulations, and
are now not needed since the ListBuilder is no longer public).
- Rewmove or replace `pub` in the define_list_builder_helper call,
so that the builder is no longer public.
- Change the main macro call site to use define_list_builder_helper.
- Add a call to define_list_builder_accessors.
* Make the module `list_builder` pub so that we have somewhere to
put the overview documentation.
* Consequential changes:
- Change `outer.inner().replace(X)` to `outer.set_inner(X)`
- Consequential changes to imports (`use` statements).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Document that this can contain either a string for expansion, or a
literal PathBuf not for expansion.
Rename the `from_path` method to `new_literal`: a very important
difference is whether it gets expanded - less important than the Rust
type. Also, now it takes `Into<PathBuf>`, which avoids a needless
clone.
(We don't change the API in `arti-client` because
`&tempfile::Tempdir()` doesn't implement `Into<PathBuf>`, so
`arti-client` has to have some new `as_ref` calls.)
Provide accessors `as_unexpanded_str` and `as_literal_path`. The
deserialisation already makes this part of the stable API,l so not
pvoding accessors seems just obstructive. They are useful for tests,
too.
Add tests for the new entrypoints, and for deserialisation of both
variants from TOML (via config, or directly) and JSON.
|