| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Cargo features are inherently additive, which means that if:
- package A walts to build package C with features ABC,
- package B walts to build package C with features BCD,
the package C will be built with *both* ABC and BCD enabled.
There is currently no way to specify mutually exclusive features
and these have to be implemented using existing, additive, ones.
That's problematic for us, because currently the cryptographic
backend in sequoia-openpgp is selected globally at build-time and
thus at most one can be selected for the compilation to succeed.
It's worth noting that we can't use Cargo build scripts to emit
the `--cfg`-passing [directive] because it does *not* affect
Cargo's dependency resolution and that's needed in order to skip
unbuildable backends on certain OSes (e.g. nettle when using Windows MSVC ABI).
To allow for other local crates, most notably sequoia-openpgp-ffi, to
build with different backends, we expose and forward any features that
may be used by the crates they transitively depend on.
At the time of writing, these different features seem to be implemented:
- buffered-reader: compression support
- openpgp: compression support and cryptographic backend
- store: background-services feature
[directive](https://doc.rust-lang.org/cargo/reference/build-scripts.html#cargorustc-cfgkeyvalue)
|
|
- 0.19 had vulnerability RUSTSEC-2020-0014.
|
|
|
|
|
|
|
|
|
|
|
|
- Use the anyhow crate instead of failure to implement the dynamic
side of our error handling. anyhow::Error derefs to dyn
std::error::Error, allowing better interoperability with other
stdlib-based error handling libraries.
- Fixes #444.
|
|
|
|
|
|
|
|
|
|
|
|
- In sq and sqv, use chrono to interface with the user.
- Fixes #341.
|
|
|
|
|
|
|
|
|
|
|
|
- 0.20 requires a newer rustc.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Also bump rfc2822 to 0.6.0. After all, we create tags for the
versions.
|
|
- Specify versions for intra-workspace dependencies in the crates
that are not yet released.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- The replacement for the deprecated function used by the previous
commit is only emitted by the newest capnp compiler. Bump the
patch version so that everyone picks it up.
|
|
|
|
|
|
|
|
- Also, avoid deprecated method in sq.
|
|
|
|
|
|
|
|
- The failure crate is a young error handling solution for Rust. It
may change the API, but since we pin our dependencies, this should
not be a problem for us, albeit a bit inconvenient.
- Introduction of the crate is a bit noisy, but not as bad as
anticipated, because failure magically handles all errors used in
the standard library.
- Matching on concrete error values requires downcasting before
matching, which seems a bit unidiomatic. This is the cost of
using and "chaining" arbitrary error types. This is something
that may be improved later on in the library or language.
- Having said that, using the error type in the tool was nice. I
did not have to use a downcast, so maybe my worries about
downcasts are unjustified because it is not such a common use case
after all. On the other hand, the tool is quite simple and our
only mode of failure is to print the message.
|
|
- Update all keys stored in a store with network policy 'encrypted'
and 'insecure' periodically using the SKS keyserver pool.
- Slightly amend the net::ipc interface so that servers can spawn
futures on the reactor.
- As a background service cannot directly communicate failures, this
patch adds a logging mechanism.
- In sq, display the key update timestamp, and the status of the
last update.
|
|
- It is not intended to be used directly, no need to clutter the
documentation with it.
|
