- Devel - lists.sequoia-pgp.org

sequoia-octopus-librnp v1.5.0
by Heiko Schäfer 04 Mar '23

04 Mar '23

Hi everyone, I'm pleased to announce the release of version 1.5.0 of the sequoia-octopus-librnp crate. The crate is published on: https://crates.io/crates/sequoia-octopus-librnp You can also fetch the code from gitlab.com using the v1.5.0 tag: https://gitlab.com/sequoia-pgp/sequoia-octopus-librnp/-/tags/v1.5.0 which Neal signed: $ git verify-tag v1.5.0 gpg: Signature made Fri 03 Mar 2023 03:57:16 PM CET gpg: using RSA key C03FA6411B03AE12576461187223B56678E02528 gpg: Good signature from "Neal H. Walfield <neal(a)walfield.org>" [full] gpg: aka "Neal H. Walfield <neal(a)gnupg.org>" [full] gpg: aka "Neal H. Walfield <neal(a)pep.foundation>" [full] gpg: aka "Neal H. Walfield <neal(a)pep-project.org>" [full] gpg: aka "Neal H. Walfield <neal(a)sequoia-pgp.org>" [full] This release fixes support for Thunderbird 102.7 and includes improvements to the automated calculation of acceptance of OpenPGP certificates (based on trust-roots defined in the user's GnuPG setup). Heiko on behalf of the whole Sequoia PGP team

1 0

Sequoia Certificate Store v0.1.0
by Neal H. Walfield 02 Mar '23

02 Mar '23

Hi everyone, I'm pleased to announce the first release of the Sequoia Certificate Store crate, sequoia-cert-store. I have published sequoia-cert-store on crates.io: https://crates.io/crates/sequoia-cert-store You can also fetch version 0.1.0 using the v0.1.0 tag: https://gitlab.com/sequoia-pgp/sequoia-cert-store/-/tags/v0.1.0 which I signed: $ git verify-tag v0.1.0 gpg: Signature made Thu Mar 02 12:01:21 2023 +01:00 gpg: using RSA key C03FA6411B03AE12576461187223B56678E02528 gpg: Good signature from "Neal H. Walfield <neal(a)walfield.org>" [ultimate] gpg: "Neal H. Walfield <neal(a)gnupg.org>" gpg: "Neal H. Walfield <neal(a)pep-project.org>" gpg: "Neal H. Walfield <neal(a)pep.foundation>" gpg: "Neal H. Walfield <neal(a)sequoia-pgp.org>" sequoia-cert-store provides a unified, high-level API for different certificate stores via its Store and StoreUpdate traits. To lookup a certificate by fingerprint given a certificate store backend, one would do: let cert = backend.lookup_by_cert_fpr(fingerprint)?; Or to lookup the certificates that have a User ID where the domain is `sequoia-pgp.org`, one would do: let certs = backend.lookup_by_email_domain("sequoia-pgp.org")?; The crate provides a number of helper functions and data structures like UserIDIndex to help a backend implement this functionality. This release includes three backends: a backend for OpenPGP certificate directories [1], a backend for certificates, e.g., as read from a keyring or other database, and a key server backend. [1] https://datatracker.ietf.org/doc/draft-nwjw-openpgp-cert-d/ Finally, the crate provides the CertStore data structure, which combines multiple backends in a transparent way to its users. Neal on behalf of the whole Sequoia PGP team

1 0

sequoia-keyring-linter v1.0.1
by Neal H. Walfield 10 Feb '23

10 Feb '23

Hi everyone, I'm pleased to announce the release of version 1.0.1 of the sequoia-keyring-linter crate. I have published sequoia-keyring-linter on crates.io: https://crates.io/crates/sequoia-keyring-linter You can also fetch 1.0.1 using the v1.0.1 tag: https://gitlab.com/sequoia-pgp/keyring-linter/-/tags/v1.0.1 which I signed: $ git verify-tag v1.0.1 gpg: Signature made Fri Feb 10 12:30:49 2023 +01:00 gpg: using RSA key C03FA6411B03AE12576461187223B56678E02528 gpg: Good signature from "Neal H. Walfield <neal(a)walfield.org>" [ultimate] gpg: "Neal H. Walfield <neal(a)gnupg.org>" gpg: "Neal H. Walfield <neal(a)pep-project.org>" gpg: "Neal H. Walfield <neal(a)pep.foundation>" gpg: "Neal H. Walfield <neal(a)sequoia-pgp.org>" This release is a minor update. A new option, `--time`, is now available, which allows the user to set a reference time. This is useful for checking if a certificate will have problems some time in the future. man page generation has also improved. And, shell completions are now generated. Several deendencies have also been updated. In particular, sq-keyring-linter now uses rpassword 6.0, and and clap 4. Neal on behalf of the whole Sequoia PGP team

1 0

sequoia-wot v0.5.0
by Neal H. Walfield 08 Feb '23

08 Feb '23

Hi everyone, I'm pleased to announce the release of version 0.5.0 of the sequoia-wot crate. I have published sequoia-wot on crates.io: https://crates.io/crates/sequoia-wot You can also fetch 0.5.0 using the v0.5.0 tag: https://gitlab.com/sequoia-pgp/sequoia-wot/-/tags/v0.5.0 which I signed: $ git verify-tag v0.5.0 gpg: Signature made Wed Feb 08 15:55:57 2023 +01:00 gpg: using RSA key C03FA6411B03AE12576461187223B56678E02528 gpg: Good signature from "Neal H. Walfield <neal(a)walfield.org>" [ultimate] gpg: "Neal H. Walfield <neal(a)g10code.com>" gpg: "Neal H. Walfield <neal(a)gnupg.org>" gpg: "Neal H. Walfield <neal(a)pep-project.org>" gpg: "Neal H. Walfield <neal(a)pep.foundation>" gpg: "Neal H. Walfield <neal(a)sequoia-pgp.org>" This release includes one significant change: certificates fetched from key servers are cached on disk in the default certificate directory. This release also includes a number of minor bug fixes. When upgrading to clap 4, the short option for `--keyring` was mistakenly changed from `-k` to `-f`. That change has been reverted. Several API warts were corrected. And, a performance bug, which impacts `sq-wot list`, was fixed. Neal on behalf of the whole Sequoia PGP team

1 0

sequoia-ipc v0.30.1
by Neal H. Walfield 02 Feb '23

02 Feb '23

Hi everyone, I'm pleased to announce the release of version 0.30.1 of the sequoia-ipc crate. I have published sequoia-ipc on crates.io: https://crates.io/crates/sequoia-ipc You can also fetch 0.30.1 using the v0.30.1 tag: https://gitlab.com/sequoia-pgp/sequoia/-/tags/ipc/v0.30.1 which I signed: $ git verify-tag ipc/v0.30.1 gpg: Signature made Thu Feb 02 15:18:54 2023 +01:00 gpg: using RSA key C03FA6411B03AE12576461187223B56678E02528 gpg: Good signature from "Neal H. Walfield <neal(a)walfield.org>" [ultimate] gpg: "Neal H. Walfield <neal(a)g10code.com>" gpg: "Neal H. Walfield <neal(a)gnupg.org>" gpg: "Neal H. Walfield <neal(a)pep-project.org>" gpg: "Neal H. Walfield <neal(a)pep.foundation>" gpg: "Neal H. Walfield <neal(a)sequoia-pgp.org>" This release includes a fix for the keybox parser. Neal on behalf of the whole Sequoia PGP team

1 0

sequoia-ipc v0.30.0
by Neal H. Walfield 01 Feb '23

01 Feb '23

Hi everyone, I'm pleased to announce the release of version 0.30.0 of the sequoia-ipc crate. I have published sequoia-ipc on crates.io: https://crates.io/crates/sequoia-ipc You can also fetch 0.30.0 using the v0.30.0 tag: https://gitlab.com/sequoia-pgp/sequoia/-/tags/ipc/v0.30.0 which I signed: $ git verify-tag ipc/v0.30.0 gpg: Signature made Wed Feb 01 16:27:00 2023 +01:00 gpg: using RSA key C03FA6411B03AE12576461187223B56678E02528 gpg: Good signature from "Neal H. Walfield <neal(a)walfield.org>" [ultimate] gpg: "Neal H. Walfield <neal(a)g10code.com>" gpg: "Neal H. Walfield <neal(a)gnupg.org>" gpg: "Neal H. Walfield <neal(a)pep-project.org>" gpg: "Neal H. Walfield <neal(a)pep.foundation>" gpg: "Neal H. Walfield <neal(a)sequoia-pgp.org>" Primary key fingerprint: 8F17 7771 18A3 3DDA 9BA4 8E62 AACB 3243 6300 52D9 Subkey fingerprint: C03F A641 1B03 AE12 5764 6118 7223 B566 78E0 2528 This release includes a fix for sequoia-ipc's gpg agent support. When decrypting a message with multiple recipients (i.e., multiple PKESK packets), sequoia-ipc's state machine would sometimes become desynchronized from gpg agent's state machine, and the decryption would fail. It also includes a fix for a test failure on big endian systems, like S390. Neal on behalf of the whole Sequoia PGP team

1 0

sequoia-wot 0.4.0 & 0.4.1
by Neal H. Walfield 31 Jan '23

31 Jan '23

Hi everyone, I'm pleased to announce the release of version 0.4.0 and 0.4.1 of the sequoia-wot crate, our web of trust engine. After releasing 0.4.0, we identified an issue that prevented building 0.4.0 in a reproducible manner. I fixed that, and then immediately released 0.4.1. sequoia-wot 0.4.0 and 0.4.1 have been published on crates.io: https://crates.io/crates/sequoia-wot You can also fetch 0.4.1 using the v0.4.1 tag: https://gitlab.com/sequoia-pgp/sequoia-wot/-/tags/v0.4.1 which I signed: $ git verify-tag v0.4.1 gpg: Signature made Wed Jan 25 16:02:18 2023 GMT gpg: using RSA key C03FA6411B03AE12576461187223B56678E02528 gpg: Good signature from "Neal H. Walfield <neal(a)walfield.org>" gpg: "Neal H. Walfield <neal(a)g10code.com>" gpg: "Neal H. Walfield <neal(a)gnupg.org>" gpg: "Neal H. Walfield <neal(a)pep-project.org>" gpg: "Neal H. Walfield <neal(a)pep.foundation>" gpg: "Neal H. Walfield <neal(a)sequoia-pgp.org>" This release includes a lot of new functionality. - sequoia-wot now supports certification networks. By default sequoia-wot works on authentication networks. An authentication network draws a distinction between two types of certifications: ones that confirm an identity should be associated with a certificate ("Alice says that this is Bob's certificate"), and ones that delegate the ability to assert identities ("Alice says that she trusts Bob when he says this is Carol's certificate"). In a certification network, all certifications delegate the ability to assert identities. This is the type of network that PGP path finding tools use, like: https://the.earth.li/~noodles/pathfind.html And the graph-paths.py tool from the Linux kernel community's wotmate: https://github.com/mricon/wotmate sq-wot exposes this functionality via the `--certification-network` option. As an example of where this is useful, let's say Sam Hartman, a previous Debian project leader, wants to authenticate a certificate for Jonathan Carter, the current Debian project leader. Unfortunately, Sam can't directly authenticate Jonathan's certificate: ``` $ sq-wot --keyring /usr/share/keyrings/debian-keyring.gpg -r 332D4CE3A2FAE5439B7E25B2283681BA6FE7F41D authenticate C7203C0A920670BF94F00BB1B01D1A72AC8DC9A1 'Jonathan Carter <jcc(a)debian.org>' No paths found. ``` Using a certification network, however, he can see that he certified Steve McIntyre's certificate, who in turn certified a different User ID on Jonathan's certificate: ``` $ sq-wot --certification-network --keyring /usr/share/keyrings/debian-keyring.gpg -r 332D4CE3A2FAE5439B7E25B2283681BA6FE7F41D authenticate C7203C0A920670BF94F00BB1B01D1A72AC8DC9A1 'Jonathan Carter <jcc(a)debian.org>' [ ] C7203C0A920670BF94F00BB1B01D1A72AC8DC9A1 Jonathan Carter <jcc(a)debian.org>: doubly authenticated (800%) Path #1 of 8, trust amount 120: ◯ 332D4CE3A2FAE5439B7E25B2283681BA6FE7F41D ("Sam Hartman <hartmans(a)debian.org>") │ certified the following certificate on 2019-06-28 ├ CEBB52301D617E910390FE16587979573442684E ("Steve McIntyre <93sam(a)debian.org>") │ certified the following certificate on 2015-08-22 ├ C7203C0A920670BF94F00BB1B01D1A72AC8DC9A1 ("Jonathan Carter <jcarter(a)linux.com>") │ certified the following binding on 2023-01-31 └ C7203C0A920670BF94F00BB1B01D1A72AC8DC9A1 "Jonathan Carter <jcc(a)debian.org>" ... ``` Sam can now reevaluate whether he is willing to consider Steve to be a trusted introducer for Jonathan. If so, he could upgrade his certification of Steve's certificate to a delegation thereby making him a trusted introducer: ``` $ sq certify --depth 1 sam.pgp steve.pgp "Steve McIntyre <93sam(a)debian.org>" ``` Sam also needs to consider whether the two User IDs on Jonathan's certificate refer to the same person. - sequoia-wot can now fetch missing certificates from key servers and WKD. The certificates are also cached locally to speed up future runs, and reduce load on the keyservers. This functionality is enabled in sq-wot by the `--network` option. It can be supplied in addition to a local keyring or alone. If a local keyring is supplied, then the certificates in the local keyring are preferred. The network backend only uses the configured keyserver if a certificate is missing. Combining this option with `--certification-network` makes sq-wot as powerful as a PGP path finding tool with access to a keyserver's database, because that's exactly what it is. - sequoia-wot understands gossip. Sometimes there are no paths from a trust root to the binding that you are trying to authenticate in the certification network. In that case, it may still be helpful to find out who has certified a particular certificate. That is, it may be helpful to listen to other's gossip. The `--gossip` option finds arbitrary paths to a particular certificate by treating all certificates as if they were trust roots albeit with zero trust. (This is similar to wotmate's graph-to-full.py.) Returning to our previous example, Sam can find out who else certified Jonathan's certificate by running: ``` $ sq-wot --gossip --keyring /usr/share/keyrings/debian-keyring.gpg authenticate C7203C0A920670BF94F00BB1B01D1A72AC8DC9A1 'Jonathan Carter <jcc(a)debian.org>' ``` - sequoia-wot includes a path validator and linter. Instead of searching for an arbitrary path in the web of trust, it is possible to validate a specific path. If the path is invalid, it is also linted: the certificates and the certifications are checked for validity (not revoked, not expired, using safe cryptography, etc.). This is particularly helpful when you think a path ought to be valid, but `sq-wot authenticate` doesn't find it. In the following example, we see that although Linus (79BE3E4300411886) certified greg k-h's certificate (38DBBDC86092693E), the path from Linus to greg k-h is not valid, because the certification uses SHA-1, which is rejected, because it is not secure: ``` $ sq-wot --keyring kernel.pgp path ABAF11C65A2970B130ABE3C479BE3E4300411886 647F28654894E3BD457199BE38DBBDC86092693E 'Greg Kroah-Hartman (Linux kernel stable release signing key) <greg(a)kroah.com>' [ ] 647F28654894E3BD457199BE38DBBDC86092693E Greg Kroah-Hartman (Linux kernel stable release signing key) <greg(a)kroah.com>: not authenticated (0%) ◯ ABAF11C65A2970B130ABE3C479BE3E4300411886 ("Linus Torvalds <torvalds(a)kernel.org>") │ No adequate certification found. │ 79BE3E4300411886 did not certify <38DBBDC86092693E, "Greg Kroah-Hartman (Linux kernel stable release signing key) <greg(a)kroah.com>"> │ No active certifications by 79BE3E4300411886 for <38DBBDC86092693E, "Greg Kroah-Hartman (Linux kernel stable release signing key) <greg(a)kroah.com>"> had a trust amount of at least 120 │ Certification (BA80 by 79BE3E4300411886 on 38DBBDC86092693E at 2011-10-25 19:51.53) is adequate, but it is not valid │ BA80 by 79BE3E4300411886 on 38DBBDC86092693E at 2011-10-25 19:51.53: policy violation │ Policy rejected non-revocation signature (GenericCertification) requiring collision resistance │ SHA1 is not considered secure since 2013-02-01T00:00:00Z └ 647F28654894E3BD457199BE38DBBDC86092693E "Greg Kroah-Hartman (Linux kernel stable release signing key) <greg(a)kroah.com>" ``` The main visible, non-functional improvement in sequoia-wot is better performance. Whereas the previous versions of the sequoia-wot library parsed and validated all certificates at start up time, the library has been restructured to only fetch, parse, and validate those certificates that are actually relevant to the given operation. Scanning the keyring, parsing, and validating the relevant certificates, and authenticating a binding takes about 100 ms on my keyring: ``` $ gpg --export --export-options export-local-sigs > keyring.pgp $ ls -lh keyring.pgp -rw-r--r-- 1 us us 30M Jan 27 15:06 keyring.pgp $ sq keyring list keyring.pgp | wc -l 834 $ time sq-wot --keyring keyring.pgp -r 8F17777118A33DDA9BA48E62AACB3243630052D9 authenticate CBCD8F030588653EEDD7E2659B7DD433F254904A 'Justus Winter <justus(a)sequoia-pgp.org>' [✓] CBCD8F030588653EEDD7E2659B7DD433F254904A Justus Winter <justus(a)sequoia-pgp.org>: fully authenticated (100%) ◯ 8F17777118A33DDA9BA48E62AACB3243630052D9 ("Neal H. Walfield <neal(a)g10code.com>") │ certified the following binding on 2022-10-07 └ CBCD8F030588653EEDD7E2659B7DD433F254904A "Justus Winter <justus(a)sequoia-pgp.org>" real 0m0.107s user 0m0.056s sys 0m0.051s ``` This is about three times longer than `gpg --list-keys CBCD8F030588653EEDD7E2659B7DD433F254904A`. Unlike sq-wot, however, gpg uses a cache. Listing all authenticated bindings using `sq-wot list` takes 4.5 seconds on my test system. Running `gpg --check-trustdb` takes significantly longer: ``` $ time gpg --check-trustdb real 1m29.038s user 1m1.604s sys 0m27.420s $ time sq-wot --keyring keyring.pgp -r 8F17777118A33DDA9BA48E62AACB3243630052D9 list >/dev/null real 0m4.270s user 0m4.154s sys 0m0.116s ``` This performance improvement was achieved by restructuring how the web of trust engine fetches certificates. Instead of having to provide all of the certificates upfront, the engine looks up certificates using a storage abstraction, the new Store and Backend traits. https://docs.rs/sequoia-wot/0.4.1/sequoia_wot/store/index.html This storage abstraction can be implemented by applications to interface with their own certificate stores, e.g., an SQLite database, etc. Neal on behalf of the whole Sequoia PGP team

1 0

sequoia-openpgp: 1.12.0
by Neal H. Walfield 06 Jan '23

06 Jan '23

Hi everyone, I'm pleased to announce the release of version 1.1.4 of the buffered reader crate. It has been published on crates.io: https://crates.io/crates/buffered-reader You can also fetch it using the buffered-reader/v1.1.4 tag: https://gitlab.com/sequoia-pgp/sequoia/-/tags/buffered-reader%2Fv1.1.4 which I signed: $ git verify-tag buffered-reader/v1.1.4 gpg: Signature made Fri Jan 6 21:40:10 2023 GMT gpg: using RSA key C03FA6411B03AE12576461187223B56678E02528 gpg: Good signature from "Neal H. Walfield <neal(a)walfield.org>" gpg: "Neal H. Walfield <neal(a)g10code.com>" gpg: "Neal H. Walfield <neal(a)gnupg.org>" gpg: "Neal H. Walfield <neal(a)pep-project.org>" gpg: "Neal H. Walfield <neal(a)pep.foundation>" gpg: "Neal H. Walfield <neal(a)sequoia-pgp.org>" This release fixes a performance bug in the generic buffered reader (`buffered_reader::Generic`). When the amount of data that is requested (e.g., via `BufferedReader::data`) exceeds the default buffer size, exactly that amount of data was read from the underlying reader. This is problematic for two reasons. First, as users of a buffered reader often do not immediately consume the data that is read, most reads are forwarded to the underlying buffered reader. Second, most reads are for one byte. Because `buffered_reader::Generic` keeps all data in a single vec, this resulted in a lot of copying, which hurt performance. Neal on behalf of the whole Sequoia PGP team

1 0

sequoia-openpgp: 1.12.0
by Neal H. Walfield 13 Dec '22

13 Dec '22

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(a)walfield.org>" gpg: "Neal H. Walfield <neal(a)g10code.com>" gpg: "Neal H. Walfield <neal(a)gnupg.org>" gpg: "Neal H. Walfield <neal(a)pep-project.org>" gpg: "Neal H. Walfield <neal(a)pep.foundation>" gpg: "Neal H. Walfield <neal(a)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

1 0

sequoia-openpgp: 1.11.0
by Neal H. Walfield 18 Nov '22

18 Nov '22

Hi everyone, I'm pleased to announce the release of version 1.11.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.11.0 tag: https://gitlab.com/sequoia-pgp/sequoia/-/tags/openpgp%2Fv1.11.0 which I signed: $ git verify-tag openpgp/v1.11.0 gpg: Signature made Fri 18 Nov 2022 02:28:42 PM CET gpg: using RSA key C03FA6411B03AE12576461187223B56678E02528 gpg: Good signature from "Neal H. Walfield <neal(a)walfield.org>" [ultimate] gpg: aka "Neal H. Walfield <neal(a)gnupg.org>" [ultimate] gpg: aka "Neal H. Walfield <neal(a)pep.foundation>" [ultimate] gpg: aka "Neal H. Walfield <neal(a)pep-project.org>" [ultimate] gpg: aka "Neal H. Walfield <neal(a)sequoia-pgp.org>" [ultimate] Primary key fingerprint: 8F17 7771 18A3 3DDA 9BA4 8E62 AACB 3243 6300 52D9 Subkey fingerprint: C03F A641 1B03 AE12 5764 6118 7223 B566 78E0 2528 The most notable change in this release is support for v3 signatures. RFC 4880 says: Implementations SHOULD accept V3 signatures. Implementations SHOULD generate V4 signatures. https://www.rfc-editor.org/rfc/rfc4880#section-5.2 Although the recommendation from 2007 is clear that v4 signatures should be preferred, the rpm ecosystem still generates v3 signatures. As Panu Matilainen, the maintainer of rpm, says: this appears to be more because it was forgotten about than out of any desire to stick with v3, and now it is time to figure out how to move on: [I]t IS us the rpm-ecosystem who has been sleeping here. The good news is that V3 doesn't appear to be heartbleed critically flawed, just that V4 is better and everybody should be using that instead. ... This caught us all by surprise. It's just another piece of rusty but vitally important piping in the backyard that everybody had forgotten until it bust open. It's a good thing this was discovered, now lets just move on to fix this up https://bugzilla.redhat.com/show_bug.cgi?id=2141686#c29 But, moving to v4 signatures will take time, because resigning all existing packages is infeasible. So, to accommodate reality, sequoia-openpgp is now able to parse and verify v3 signatures. By default, they are forbidden by the standand policy; an application must opt in to them using `StandardPolicy::accept_packet_tag_version`. https://docs.rs/sequoia-openpgp/1.11.0/sequoia_openpgp/policy/struct.Standa… Other user visible changes are listed in the NEWS file: https://gitlab.com/sequoia-pgp/sequoia/-/blob/openpgp/v1.11.0/openpgp/NEWS Neal

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

Devel