Hi all,
I'm pleased to announce the release of version 1.17.0 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.17.0 using the openpgp/v1.17.0 tag:
https://gitlab.com/sequoia-pgp/sequoia/-/tags/openpgp/v1.17.0
which I signed:
$ git verify-tag openpgp/v1.17.0 gpg: Signature made Fri Oct 27 09:21:43 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 release includes significant testing improvements, infrastructure upgrades, new functionality, performance increases, and a number of minor bug fixes.
# Testing Improvements
This release includes a new "null" crypto backend, which faciliates fuzzing:
https://gitlab.com/sequoia-pgp/sequoia/-/commit/a4c2b9f50a9f6e6539154eb3bcef...
Fuzzing works by passing invalid or malformed input to a function to uncover defects. As decryption and signature verification is highly sensitive to malformed input, the cryptography routines would quickly reject malformed input, which prevented the fuzzer from exercising the non-crypto related code.
The null crypto backend faciliates fuzzing by accepting pretty much anything. Specifically, it uses a highly optimized version of double ROT-13 to encrypt and decrypt data, and indicates that all signatures are valid. This fuzzing uncovered a bug, which has also been fixed:
https://gitlab.com/sequoia-pgp/sequoia/-/commit/3c76d468060a02b0aa129308bc41...
There is also a new framework to detect secrets that are leaked to the heap or stack. This happens when memory that stores a secret is not erased after it is deallocated. Erasing secrets can help prevent heartbleed-style attacks.
See, in particular, this commit for a lot of technical details and a description of the approach:
https://gitlab.com/sequoia-pgp/sequoia/-/commit/c62fb995baee091ef6009a06068b...
The good news is that most crypto backends are good at protecting their secrets. One issue was reported to the Rust aes crate, and a partial fix has since been committed:
https://github.com/RustCrypto/block-ciphers/issues/385
# Infrastructure Upgrades
On the infrastructure side, we now use Sequoia git to enforce a signing policy:
https://gitlab.com/sequoia-pgp/sequoia/-/commit/18dd64b9548ad151fdfa0ec8f679...
Sequoia git is a new tool that we've been working on to simplify the articulation and verification of a signing policy:
https://gitlab.com/sequoia-pgp/sequoia-git
The basic idea is that a file, `openpgp-policy.toml`, is added to a git repository. It contains a list of who is authorized to add commits, sign tags, and change the policy. The `sq-git` CLI can then be used to ensure that a version (e.g., a commit) is an authorized derivation in the sense that each change made since an earlier, known good version (the trust root) is consistent with a parent commit's signing policy. More details are in the specification:
https://sequoia-pgp.gitlab.io/sequoia-git/
Using this tool, downstream users can detect changes that were not authorized by the upstream developers, e.g., modifications by a package registry, a forge, or some other machine in the middle.
Using the commit where the signing policy was added as our trust root, we can authenticate all commits up to the openpgp/v1.17.0 tag:
$ sq-git log --trust-root 18dd64b9 openpgp/v1.17.0 && echo Authenticated. 81d59e96ea37083b187909f12d298e5196c65130..65448ef8932cc8136b67445267e0f9849b7395c0: neal [74E445BA0E15C957] ... Authenticated.
# New Functionality
Sequoia now includes better support for early v4 certificates. These certificates often lacked a key flags subpacket. Previously, Sequoia would consider these certificates to be unusable, as it concluded the keys had no capabilities. Now, Sequoia more closely matches the behavior of other implementations by inferring the key flags from the algorithm, and the key's role (i.e., whether it is a primary key or a subkey). See:
https://gitlab.com/sequoia-pgp/sequoia/-/commit/9e48a064e55e5ee61bc8caf6d7d0...
This release adds support for Camellia and DSA to the Rust Crypto backend:
https://gitlab.com/sequoia-pgp/sequoia/-/commit/e2cb5bafb95fea51328238acac90... https://gitlab.com/sequoia-pgp/sequoia/-/commit/13d56eddcaa3925fb3bfa8ef4226...
Note: the algorithms supported by each of the backends is listed on the status page:
https://sequoia-pgp.org/status/
Sequoia now also uses SHA-1 CD in place of SHA-1 everywhere.
https://gitlab.com/sequoia-pgp/sequoia/-/commit/5188c044b9f6645dd05a0918d4a9...
# Performance Increases
Generating a certificate is now much faster. Previously, the certificate was canonicalized after each key was added. For a certificate with a primary key and two subkeys, this means that it was canonicalized three times. Each time a certificate is canonicalized, all of the signatures are checked. Now, the certificate is only canonicalized once, at the end.
https://gitlab.com/sequoia-pgp/sequoia/-/commit/4a2c51173f9dc48ebd8649982388...
Neal on behalf of the whole Sequoia PGP team
-
Neal H. Walfield