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.
Add some wrapper functions for convenience.
The pwd-grp crate has a richer and more faithful, but not so
convenient, way of creating dummy user/group entries. Also the type
names are all going to change.
Doing this now reduces churn.
The actual underlying operations here *are* fallible.
The `users` crate hides those errors in several cases.
(Failures are very rare (at least unless NIS is involved), so this is
not of much practical import, but it's going to be necessary when we
use the more careful pwd-grp crate.
When we implemented bridges, we added code in 08473872ab to
conditionally mark their directory info as present or not present.
But the we didn't remove the old code to mark them present
unconditionally!
Fixes#638.
- 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.
There are a number of places where we generate random Durations
in a range which starts at zero.
These call sites currently (i) have to write out Duration::ZERO
or equivalent, and (ii) would have to use gen_range_checked and expect
the result, even though it can be statically proven to be OK.
To make this slightly smoother, provide `GenRangeInfallible` and
`gen_range_infallible`.
Ideally we would be allowed to use vanilla gen_range() here, but there
doesn't seem to be a way to allow a specific clippy-forbidden method
using #[allow] and we probably don't want to make a blanket allow.
This launders the closure so that clippy's
clippy::redundant_closure_call can't see it.
We can't have a local #[allow] because it would be on an expression,
which isn't allowed on stable.
This avoids having to use more clumsy idioms at call sites.