sequoia-openpgp: 1.12.0 - Devel - lists.sequoia-pgp.org

13 Dec 2022


      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