Done with the commands below.
The following crates have had various changes, and should get a
patchlevel bump. Since they are pre-1.0, we do not need to
distinguish new APIs from other changes.
```
cargo set-version --bump patch -p arti-client
cargo set-version --bump patch -p safelog
cargo set-version --bump patch -p tor-bytes
cargo set-version --bump patch -p tor-cert
cargo set-version --bump patch -p tor-circmgr
cargo set-version --bump patch -p tor-config
cargo set-version --bump patch -p tor-consdiff
cargo set-version --bump patch -p tor-dirclient
cargo set-version --bump patch -p tor-dirmgr
cargo set-version --bump patch -p tor-error
cargo set-version --bump patch -p tor-hsservice
cargo set-version --bump patch -p tor-linkspec
cargo set-version --bump patch -p tor-llcrypto
cargo set-version --bump patch -p tor-netdir
cargo set-version --bump patch -p tor-netdoc
cargo set-version --bump patch -p tor-proto
cargo set-version --bump patch -p tor-rpcbase
cargo set-version --bump patch -p tor-socksproto
```
This crate has new features, but no new non-experimental Rust APIs.
So even though it is post-1.0, it gets a patchlevel bump.
```
cargo set-version --bump patch -p arti
```
These crates have had nonfunctional changes only, mostly due to !1271,
or ac90cb7500, or documentation changes: crates that depend on
them do not require a version bump.
```
arti-bench
arti-config
arti-hyper
arti-testing
caret
fs-mistrust
retry-error
tor-async-utils
tor-basic-utils
tor-chanmgr
tor-checkable
tor-congestion
tor-consdiff
tor-events
tor-guardmgr
tor-persist
tor-protover
tor-ptmgr
tor-rtcompat
tor-rtmock
tor-units
```
This was super confusing and fragile. Amongst the problems:
* Information about exceptional config keys was spread across a
number of places, manipulated in ad-hoc ways (conditional Vec
appends, etc).
* As a consequence, each exceptional table has confusing and unclear
semantics.
* It doesn't deal well with the way that cargo sometimes enables
features for dependency crates even if arti itself wouldn't demand
them; this can lead to sub-crates supporting config keys when the
tests in arti don't expect them to, causing spurious test failures.
Fix this:
* Introduce a new, systematic, way of writing information about
configuration keys that need some kind of special handling.
* Use this new approach in *both* sets of "thorough" config tests.
* Be more relaxed about deprecated keys. We don't want to tightly
couple this to absence in the supported file, I think.
* Understand more clearly the concept of keys of which we don't know,
in the current build config, whether the code is expected to
accept them.
I have tested this locally with:
for p in '-p arti' '--workspace'; do for f in '--no-default-features --features=tokio,native-tls' '--all-features' ''; do nailing-cargo test $p $f; done; done
=========================
Notes from nickm:
(This differs from pinkforest's original MR: It removes the
Cargo.lock changes and the version bump on tor-llcrypto.)
Minimal Cargo.lock changes from downgrade.
(These are exactly those changes generated by running "build" and
"test".)
There are several reasons to do this:
* It's best to bump all of our dalek dependencies at once to rc.3
or later, rather than the piecemeal approach we've been stuck
with so far.
* We don't want to do this bump right now, since there are some
tricky questions about clamping we need to figure out (see
#808), and we need to make sure we get them right, and we're in
a distracted this week.
* We _do_ need to move away from 2.0.0-rc.2 right now, since
it was causing a failure in `cargo install arti`, and then it
got yanked.
Thanks to pinkforest for helping us out here and explaining all of
this!
Fixes#926.
Commit-edited-by: Nick Mathewson <nickm@torproject.org>
This moves the filesystem calls from the `ssh` module to
`ArtiNativeKeyStore`. While `ArtiNativeKeyStore` shouldn't be concerning
itself with filesystem operations either, that refactoring will be
tackled separately (see arti#899).
- This adds a new crate, `tor-geoip`, which can parse and perform
lookups in the GeoIP database C-tor already uses (generated by a
maintenance utility in the C-tor codebase).
- We embed a copy of C-tor's databases with the crate and use
`include_str!` to ship them with the binary, bloating its size
somewhat.
- This does, however, solve the problem of figuring out how to
distribute these.
- The plan is to gate this functionality behind a feature flag anyway,
so the cost should be nil unless explicitly opted into.
Part of tpo/core/onionmasq#47.
The HS `HsClientSpecifier` and `HsClientSecretKeySpecifier` are moved to
`tor-hsclient`. The HS service secret key specifier stubs are moved to
`tor-hsservice`.
We need the fix from [82d69902], which first appeared in async-trait
version 1.54. (Technically we only need this fix in tor-hsclient,
but we may as well update our minimal async-trait version everywhere.)
[82d69902]: 82d6990253
This contains code to:
* Iterate over introduction points
* Make multiple attempts to connect
* Apply timeouts to the various phases of each attempt
* Establish a rendezvous point
* Represent errors that occur during the above
It provides places to add:
* Implementation of the INTRODUCE1/INTRODUCE_ACK handshake
* Reception of RENDEZVOUS2 and actual end-to-end circuit establishment
* Recording of the outcome of connection attempts via particular IPTs
* Using previous IPT outcome information for selecting IPTs to try
* Tests of the new code (although more mocking will probably be needed)
Much of this code works with a fixed type ClientCirc rather than going via
the Mockable traits. That is wrong, and it will be fixed later.
The actual decoding here is just a placeholder. The important part
is that we can get either a (SessionId, StreamId) tuple out of the
request, or we treat it as part of an isolation token.
This commit has a few TODOs for additional things that we'll need
in order to build out our design.
These identifiers are actually only "global" with respect to a given
`RpcMgr`, but they should not be forgeable or reusable across RpcMgr
objects. We're going to use them so that we have a kind of identifier
for `TorClient`s that we can expose to SOCKS.
Nick Mathewson
Gabriela Moldovan
Ian Jackson
Ian Jackson
pinkforest
eta
Alexander Færøy