Fwd: OpenPGP interoperability issues with gnupg >= 2.4
Sam James <[email protected]> Mon, 6 Feb 2023 20:27:57 +0000
| Newsgroups | dev.linux.lists.distributions |
|---|---|
| Message-ID | <[email protected]> |
> Begin forwarded message: > > From: David Runge <[email protected]> > Subject: OpenPGP interoperability issues with gnupg >= 2.4 > Date: 6 February 2023 at 20:24:27 GMT > To: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] > > Hi all, > > I am one of the package maintainers of gnupg on Arch Linux. > DISCLAIMER: Since December 2022 I am also a contracted developer for the > Sequoia project (an alternative implementation of the OpenPGP standard > in Rust). > > We (Levente Polyak and I) are writing to you because you are the > maintainers of gnupg on other downstream distributions. > With gnupg 2.4.0 a change has been merged [1], which has gpg operate > with certificate material in a way that is incompatible with the > upcoming IETF approved "crypto-refresh" approach. > This means, that e.g. messages encrypted using a key generated with > gnupg >= 2.4.0 will not be compatible with OpenPGP implementations > following the upcoming IETF standard. > > While this has especially integrators such as Thunderbird [2] and > keyserver authors worried, it is also a concern for us as a downstream > distributor of gnupg. > Some of you have already updated gnupg to >= 2.4.0 in some form, but we > would like to take the time and open the discussion on this topic, as we > believe that the change is harmful to the larger OpenPGP ecosystem. > > We are currently still shipping 2.2.x due to (only now resolved) issues > with our distribution keyring. However, we are wondering how to proceed > with gnupg in the future, as it will also negatively affect the trust > model of our own distribution. > > Several scenarios seem likely (depending on adoption): > > * notifying users of upcoming incompatibilities if they create a key > with gnupg >= 2.4.0 > * shipping/ using gnupg 2.2.x alongside (or exclusively) for as long as > possible > * undoing the change in gnupg > > We would like to raise awareness and gather some feedback of current > packagers of gnupg to form a broader response to this issue. > > As mail threads with large To: headers might get very tedious for > discussing this topic, we would also like to invite you to > #openpgp-interop on libera.chat [3]. > > Best, > David and Levente > > P.S.: The addressed persons have been gathered via links to downstream > source data on repology.org [4]. In case we have missed anyone (very > likely), that should join the discussion, please feel free to forward > this e-mail to them. > > [1] https://lists.gnupg.org/pipermail/gnupg-devel/2022-December/035183.html > [2] https://lists.gnupg.org/pipermail/gnupg-devel/2023-February/035270.html > [3] ircs://irc.libera.chat/openpgp-interop > [4] https://repology.org/project/gnupg/versions > > -- > https://archlinux.org
signature.asc
(application/pgp-signature, 358 B)
-----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCY+FizV8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MAAKCRBzhAn1IN+R kJ3PAP9JnD6Z2oFhKktAorJeWBGMPP2Y3/y8WKg+knS2RrKS0AD/SKOhUGagUBfN nv8TzFtbTsB7sv7Wvf6PcVrLyznFxw8= =vY/5 -----END PGP SIGNATURE-----