Hi everyone,
I'm pleased to announce the release of version 1.12.0 of the sequoia-openpgp crate. It has been published on crates.io:
https://crates.io/crates/sequoia-openpgp
You can also fetch it using the openpgp/v1.12.0 tag:
https://gitlab.com/sequoia-pgp/sequoia/-/tags/openpgp%2Fv1.12.0
which I signed:
$ git verify-tag openpgp/v1.12.0 gpg: Signature made Tue Dec 13 16:14:59 2022 GMT gpg: using RSA key C03FA6411B03AE12576461187223B56678E02528 gpg: Good signature from "Neal H. Walfield neal@walfield.org" gpg: "Neal H. Walfield neal@g10code.com" 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"
The main reason for this release is to fix an issue with a dependency. sequoia-openpgp v1.11.0 depended on version 0.12 or later of the base64 crate. Version 0.20 of the base64 crate was recently released with an incompatible API. This means that when an application uses sequoia-openpgp, it may try and to use version 0.20 of base64, and compilation will fail. Version 1.12.0 tightens the dependency. We expect that the next version of sequoia-openpgp will upgrade to version 0.20 of base64.
This release also includes a fix for how text data is hashed [1]. When sequoia-openpgp hashes a text (signature type = "0x01: Signature of a canonical text document" [2]), it breaks the input into to blocks. Unlike for signatures over data, for signatures over text, the line endings `\n`, `\r`, and `\r\n` are canonicalized to `\r\n`. Unfortuantely, if a '\r\n' is split across two blocks, sequoia-openpgp would recognize two line endings instead of one, and hash too much data.
This defect does not impact binary signatures, and in practice it is relatively uncommon as a line ending has to straddle two blocks. Nevertheless, this defect may have resulted in the creation of incorrect signatures, or correct signatures being incorrectly identified as invalid.
[1] https://gitlab.com/sequoia-pgp/sequoia/-/issues/960 [2] https://www.rfc-editor.org/rfc/rfc4880#section-5.2.1
Neal on behalf of the whole Sequoia PGP team