Hi all,
I'm pleased to announce the release of version 1.16.1 of sequoia-openpgp, our low-level OpenPGP library.
I have published sequoia-openpgp on crates.io:
https://crates.io/crates/sequoia-openpgp
You can also fetch version 1.16.1 using the openpgp/v1.16.1 tag:
https://gitlab.com/sequoia-pgp/sequoia/-/tags/openpgp/v1.16.1
which I signed:
$ git verify-tag openpgp/v1.16.1 gpg: Signature made Tue Sep 26 11:27:04 2023 +02:00 gpg: using RSA key C03FA6411B03AE12576461187223B56678E02528 gpg: Good signature from "Neal H. Walfield neal@walfield.org" [ultimate] gpg: "Neal H. Walfield neal@gnupg.org" gpg: "Neal H. Walfield neal@pep-project.org" gpg: "Neal H. Walfield neal@pep.foundation" gpg: "Neal H. Walfield neal@sequoia-pgp.org"
This is a minor bug fix release. Unfortunately, due to a limitation in cargo's dependency resolver, it is not possible to ensure that two dependencies use the same version of a third crate. With the recent release of win-crypto-ng, this leads a build failure when compiling sequoia-openpgp with an up-to-date Cargo.lock file.
The specific problem is:
- ed25519-dalek version 1.0.1 depends on rand_core 0.5; - the latest release of win-crypto-ng (0.5.1) depends on rand_core 0.5 or 0.6; - cargo compiles ed25519-dalek against rang_core 0.5, and win-crypto-ng against rand_core 0.6; - sequoia-openpgp passes an object returned by win-crypto-ng to ed25519-dalek; - ed25519-dalek requires that that object implement a trait exported by rand_core; - rustc (correctly) considers the trait from rand_core 0.5 to be different from the trait with the same name from rand_core 0.6, and complains.
This can be fixed by manually running:
cargo update -p win-crypto-ng --precise 0.5.0
This forces the use of an old version of win-crypto-ng. As it is tricky for end users to figure out that this is necessary, 1.16.1 forces the use of win-crypto-ng 0.5.0.
See https://gitlab.com/sequoia-pgp/sequoia/-/issues/1052 for more details. Thanks to Jens Reimann for reporting the issue.
Neal on behalf of the whole Sequoia PGP team