!1410 and !1412 had a semantic conflict *in the Cargo lockfile*!
!1410 added a new indirect dependency on derive-adhoc, which is used
in pwd-grp. pwd-grp is still declaring a dependency on d-a 0.6.1.
(This ought to be updated there in due course, but isn't a bug.)
!1412 updated our direct dependency on derive-adhoc to require 0.7.x.
In fact, the breaking change 0.6.x to 0.7.x is minor and we could have
written a more relaxed dependency.But cargo's syntax for that is very
clumsy - here is an example from derive-adhoc iteself:
itertools = ">=0.10.1, <0.12"
Fix this for now in our tree with a `cargo update`, to unbreak main.
users is unmaintained. pwd-grp is the crate I have just written to
replace it. In this commit:
Change the cargo dependency and imports.
Replace the cacheing arrangements. users has a built-in cache;
pwd-grp doesn't. Now, instead of cashing individual lookups, we cache
the trusted user and trusted gid calculation results.
This saves on some syscalls, and is also more convenient to write.
(Mocking is still done via the dependency.)
Many systematic consequential changes of details:
* The entrypoint names to the library are different:
pwd-grp uses the names of the corresponding Unix functions.
* pwd-grp's returned structs are transparent, so we don't
call accessors for .uid(), .name(), etc.
* pwd-grp's methods are much more often fallible
(returning io::Result<Option<...>)
* We're using the non-UTF-8 pwd-grp API, which means we must
use turbofish syntax in some places.
* The mocking API is a bit different.
- When the `geoip` feature flag of `tor-netdir` is enabled, perform
GeoIP lookups for all relays added to the directory and add the
resulting country code to the `Relay` struct.
- The GeoIP database is provided in a new
`PartialNetDir::new_with_geoip` constructor.
- A new trait was also added to `tor-linkspec`, `HasCountryCode`, to
enable getting this data out from other crates.
Part of onionmasq#47.
Previously, the keystore config consisted of a single field in
`StorageConfig`, which encoded 2 bits of information: whether the
keystore is enabled, and its root directory:
```
[storage]
# use this path, fail if compiled out
# keystore = "/path/to/arti/keystore"
#
# use default path, fail if compiled out
# keystore = true
#
# disable
# keystore = false
```
This commit adds `ArtiNativeKeystoreConfig`, which will replace the
multi-purpose `keystore` field. The new config will look like this:
```
#[storage.keystore]
# Whether the keystore is enabled.
#
# If the `keymgr` feature is enabled and this option is:
# * set to false, we will ignore the configured keystore path.
# * set to "auto", the configured keystore, or the default keystore, if the
# keystore path is not specified, will be used
# * set to true, the configured keystore, or the default keystore, if the
# keystore path is not specified, will be used
#
# If the `keymgr` feature is disabled and this option is:
# * set to false, we will ignore the configured keystore path.
# * set to "auto", we will ignore the configured keystore path.
#
# Setting this option to true when the `keymgr` feature is disabled is a
# configuration error.
#enabled = "auto"
# The root directory of the arti keystore
#path = "${ARTI_LOCAL_DATA}/keystore"
```
While `ArtiNativeKeystoreConfig` currently only has 2 fields, `enabled`
and `path`, future versions of the keystore might require additional
config options.
This abolishes some quintuplication.
The output is identical except that:
* The syntax display in the rustdoc output for the resulting macros
seems to have somewhat less whitepsace.
* The whimsical error messages in the examples are all identical.
Ah well.
The main contribution here is a set of convenience macros for
logging error `Report`s. Notably, this macros always logs
`Internal` and `BadAspiUsage` errors at `WARN`, unless they
are already at `ERROR` or more.
This is a little tricky because `tracing::event!()` requires
its Level argument to be a constant.
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>
Ian Jackson
Alexander Færøy
Nick Mathewson
gabi-250
eta
Ian Jackson
trinity-1686a
pinkforest