This does the following:
- Gives every crate a `full`.
- Cause every `full` to depend on `full` from the lower-level
crates.
- Makes every feature listed _directly_ in `experimental` depend
on `__is_experimental`.
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 <gabi@torproject.org>
These crates had no changes until just a moment ago. But since
we updated the versions on some of their dependents, they have now
changed themselves. Thus they get patchlevel bumps.
```
tor-rtmock
tor-protover
tor-socksproto
tor-consdiff
tor-chanmgr
tor-dirclient
tor-hsservice
```
For these crates, the changes are nontrivial, so we
_do_ bump the versions on which their dependent crates depend.
Fortunately, since they are all pre-1.0, we don't need to
distinguish semver-additions from other changes. (Except for arti,
which _is_ post-1.0, but gets a patchlevel bump anyway.)
These are unstable crates with breaking changes:
```
tor-hscrypto
tor-hsclient
```
These have new or extended APIs:
```
safelog
tor-bytes
tor-cell
tor-linkspec
tor-llcrypto
tor-proto
tor-cert
arti-client
```
These have new unstable APIs or features:
```
tor-netdoc
tor-circmgr (also broke some unstable APIs)
arti (is post-1.0)
```
These have bugfixes only:
```
caret
tor-dirmgr
```
I found that I had the bug where I forgot to call this function, and
reached
bad_api_usage!("The circuit launcher wasn't initialized")
The possibility of such a bug is a hazard of this API pattern.
We're going to want to reuse this.
Also: rename StreamPrefs::isolation and update the docs, to better
reflect its rather limited functionality. The new
TorClient::isolation is the only call site.
When I was trying to add HS support to these layers, I found I could
add a new variant to the `Host` enum but everything would still
compile even though I hadn't written the necessary implementation!
This method is a liability: when using it, one inevitably writes such
latent bugs.
Doing so doesn't seem like a good idea. It might even be some kind of
leak?
Found because I added a variant to `address::Host` for hidden
services, and noticed that the resolve code still compiled.
These crates have had small code changes, but no API additions:
tor-config
tor-socksproto
tor-cert
tor-chanmgr
tor-ptmgr
tor-guardmgr
tor-circmgr
tor-dirclient
tor-dirmgr
arti
tor-hsservice
tor-congestion
These crates have had API extensions:
fs-mistrust
tor-llcrypto
tor-bytes
tor-checkable
tor-linkspec
tor-netdoc
tor-persist
arti-client
These are API breaks, but the crates themselves are currently
100% experimental, so there's no need to bump the minor versions
according to our semver rules.
In !948 we renamed a couple of accessor functions, which is a
breaking change in `tor-cell`'s API.
In retrospect, perhaps we should have deprecated the old names and
added the new ones, so we wouldn't have to break the API. (This is
the only API break AFAICT since 1.1.0.)
These changes influence behavior, but not effect compatibility.
(If I messed up, and any crate except for `arti` has non-breaking
API changes, that's still fine, since they are all version
0.x.)
Change ErrorHint so that, internally, it just holds an enum with a
lightweight reference to whatever parts of the error it needs to
generate a hint. Then we can move the formatting logic into a
Display function for ErrorHint, and do away with ErrorDetail entirely.
Move the "hint" function into Error, and use Option rather than Result.
(I'm using Option here because it's not really an error case not to have
a hint; we just either have a hint, or we don't.)
This warning kind of snuck up on us! (See #748) For now, let's
disable it. (I've cleaned it up in a couple of examples, since
those are meant to be more idiomatic and user-facing.)
Closes#748.
There's no harm in doing this, since we'll try to take ownership of
the state soon as soon as we use it: We just want to try early, so
that we'll get it before we decide that we're using bridges.
Fixes bug #669; bug introduced by !889.
This makes a `pt_state` directory inside .local/share/arti (or the
local equivalent), right next to our existing `state` dir.
Ideally we would use a separate directory for each PT, but we have a
very fuzzy "what is a specific PT" notion.
Closes#667
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.
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 :-).
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.)
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`.
Having this done within circmgr was irregular - most of our other key
buildup functions are done in TorClient::create_inner.
It is also inconvenient, as it buries the guardmgr within the circmgr.
0.99.[012] have a bug https://github.com/JelteF/derive_more/issues/114
which makes the Deref derive for bridgedesc::StateGuard not work
and therefore breaks minimal-versions CI.
It seems simpler to require the newer version everywhere.
The feature we want is `#[doc = include_str!("README.md")]`, which is
stable since 1.54 and our MSRV is now 1.56.
This commit is precisely the result of the following Perl rune:
perl -i~ -0777 -pe 's{(^//!(?!.*\@\@).*\n)+}{#![doc = include_str!("../README.md")]\n}m' crates/*/src/lib.rs
Add ,ignore to ignore three examples that don't actually compile.
cargo readme would add these annotations to lib.rs, but the doc
include doesn't do stuff like that. pandoc seems to still render the
result just fine.
(Since the APIs for the `Schedule::sleep*` functions changed, this
is a breaking change in tor-rtcompat. Therefore, the Runtime trait
in tor-rtcompat is now a different trait. Therefore, anything that
uses the Runtime trait in its APIs has also broken.)
Because we want to work more on ensuring that our semver stability
story is solid, we are _not_ bumping arti-client to 1.0.0 right now.
Here are the bumps we _are_ doing. Crates with "minor" bumps have
had API breaks; crates with "patch" bumps have had new APIs added.
Note that `tor-congestion` is not bumped here: it's a new crate, and
hasn't been published before.
```
tor-basic-utils minor
fs-mistrust minor
tor-config minor
tor-rtcompat minor
tor-rtmock minor
tor-llcrypto patch
tor-bytes patch
tor-linkspec minor
tor-cell minor
tor-proto minor
tor-netdoc patch
tor-netdir minor
tor-persist patch
tor-chanmgr minor
tor-guardmgr minor
tor-circmgr minor
tor-dirmgr minor
arti-client minor
arti-hyper minor
arti major
arti-bench minor
arti-testing minor
```
This is not interesting to the user, and violates some of our
safe-logging rules (like "Don't log at info for each user request"
and "don't log ports").
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.
The parameter to FileWatcher::new is not a polling time fallback; it
is a "debounce time". Events are always delayed by at least this
much.
10s is much too long for this. 1s is more appropriate.
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.
The chanmgr remembers the last dormancy state it was told.
We invent a chanmgr-specific Dormancy which the arti-client code knows
how to convert from the richer top-level dormant status. This avoids
having to have everyone know all the variants of the top-level state.
To call reconfigure_general, we must also obtain and plumb through a
netdir. Right now we must return an internal error if there is in
fact no netdir, because reconfigure_general does not yet cope with a
missing netdir.
Nothing actually *uses* the dormancy yet.
We're going to need to reuse this, so we can plumb the dormancy to
more places. Breaking it out avoids having repeat the initial
dormancy value in two places.
Do _not_ bump the dependency versions on crates that have had no
changes since arti 0.0.5, since those crates do not depend on the
new APIs.
```
cargo set-version -p tor-basic-utils --bump patch
cargo set-version -p tor-llcrypto --bump patch
git restore crates/tor-checkable
git restore crates/tor-consdiff
git restore crates/tor-rtmock
```
This performs the transitive closure of the last operation:
everything that depends on a crate with a breaking change gets the
version which it depends on bumped.
```
cargo set-version -p tor-proto --bump minor
cargo set-version -p tor-netdoc --bump minor
cargo set-version -p arti-hyper --bump minor
cargo set-version -p arti-bench --bump minor
cargo set-version -p arti-testing --bump minor
cargo set-version -p tor-config --bump minor
```
This allows us to give better errors in the case where bootstrapping
succeeds at first, but fails thereafter for long enough to make our
directory expire.
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.
We are going to want to be able to wake up other tasks elsewhere in
Arti, that need to know about dormancy. We will give them a postage
watch Receiver.
Right now there are no such things yet.
Found these by disabling the nightly dbg macro special case. Now, we
have a mechanism for globally adding suppressions to tests, we can use
that instead.
According to doc/Errors.md, and in keeping with current best
practices, we should not include display an error's `source()` as
part of that error's display method. Instead, we should let the
caller decide to call source() and display that error in turn.
Part of #323.
Rustls uses ring, which uses code from BoringSSL, which derived from
OpenSSL before OpenSSL changed their license. So ring is currently
under 3BSD/SSLEay licenses, which aren't GPL-compatible, which may
be a problem for some people.
See #493.
A "reset" happens whenever we have to start a download attempt over
-- either because we ran out of retries, or we found something wrong
with the consensus after fetching certificates.
An "error" happens when we have a recoverable error from one or more
directory sources.
A "stall" happens whenever a round of downloads or cache loads leads
to no change in the status.
We don't yet use this as part of our status reporting.
These need to be optional: they improve performance by shifting to
asm implementations, which may not be everybody's idea of good practice.
These are not 'pure' features, since they select one implementation
but disable another. Therefore they don't go in `full`.
Closes#441.