Hello, On Mon, Jul 20, 2026 at 8:36 PM CS Sushi Man via devel < [email protected]> wrote:
> I have read *some* of the ITEF mailing lists that mentioned > LibrePGP (using my spare time). It seems that some very *odd* > things have occurred. I must thank you Simo, for bringing this > issue further into my attention. I wouldn't have noticed this, if > it weren't for you. According to this email, it appears that the > compromise specification has been changed, without the awareness of > at least two stakeholders. > > https://mailarchive.ietf.org/arch/msg/openpgp/zTQNT914Av0LOR_tFsowfHvijA4/ > > I'll also add a few emails from the GnuPGP side: > > https://lists.gnupg.org/pipermail/gnupg-devel/2023-February/035271.html > https://lists.gnupg.org/pipermail/gnupg-devel/2023-February/035272.html > https://lists.gnupg.org/pipermail/gnupg-devel/2023-February/035276.html > https://lists.gnupg.org/pipermail/gnupg-devel/2023-February/035280.html > https://lists.gnupg.org/pipermail/gnupg-devel/2023-February/035281.html > > A broad search of this archive for `LibrePGP`, can be found here: > > https://mailarchive.ietf.org/arch/browse/openpgp/?q=LibrePGP > > , the most useful emails in the ITEF archive seem to be dated > earlier (circa. 2023). Feel free to dig around. There's likely more > goodies that I haven't found yet, or perhaps there are some emails > in there which significantly counter my current position? :-) > Here's one that reasonably calls into question the GnuPG maintainer's credibility on-list at the very least: https://mailarchive.ietf.org/arch/msg/openpgp/9-WktrFNuZVYZVwlAKl0J56k5Vc/ Not necessarily in the IETF archive, but there are some more objective analyses here: Roughly contemporary to list discussion: https://lwn.net/Articles/953797/ A Debian maintainer noting implementation quality & safety issues in GnuPG as a driving factor in switching to gpgv-sq for trixie: https://lwn.net/ml/debian-devel/[email protected]/ (Referenced in this LWN article about trixie: https://lwn.net/Articles/1017315/) In the comments of an LWN article from just a couple of months ago: https://lwn.net/Articles/1072870/ ...one of the authors of said article posted an insightful analysis of the current situation in response to a reader comment: https://lwn.net/Articles/1074041/ See also discussions *specifically about Fedora* and OpenPGP in this LWN article from January: https://lwn.net/Articles/1055053/ Lastly, here's a rather direct counter to both the technical and personal issues raised by LibrePGP proponents, with considerable citations to back up its claims: https://blog.pgpkeys.eu/critique-critique.html > > If true, this would essentially mean that this consensus is of > the OpenPGP specification designers, rather than the stakeholders. > These are functionally equivalent groups. Werner had considerable opportunities to engage with and shape discussion of the spec, including by submitting drafts of his own authorship. > These mailing list discussions appear to be lacking in > technicality, which is strange for a task force focused on > *engineering.* I'd expect more argumentation out of a technical > mailing list... > > I now believe that GnuPGP's maintainers have technical standing, > and that the current ITEF OpenPGP specification was likely forced > through the committee in bad faith. This is my opinion, and I > believe that everyone reading, should read these emails > yourselves, including emails that I have *not* chosen to be > linked. Please, come to your own conclusions about what might be > happening here, and feel free to state them loud and clear. > You appear to have come to this conclusion based on a substantially limited corpus of discussion around the issue, primarily based on the viewpoints of the single developer who has elected to diverge from consensus. See also some of the writing linked above that deconstructs any notion of "technical standing" LibrePGP compo > > Compatibility is the current hot-topic. Be very careful, stop and > *think* when you see this word being used. This word may be used > improperly in this mailing list in the very near future, as well as > some other words, like "interoperability." Check and make sure that > they are using the technical definitions of these words, and that > their usage of the word is coherent, and sound. > This kind of language is rather fear-mongering in nature without a sound basis. If you can provide concrete examples of the behavior you anticipate will happen on this list in the "very near future", that would be appreciated; otherwise, I struggle to find value in this statement. The core issue here, as Simo has pointed to, is interoperability in its simplest and most straightforward sense. To quote Simo: >The "LibrePGP maintainers" had a voice in the OpenPGP WG like everyone else. > > OpenPGP is a standard, the standard is discussed and negotiated and > agreed in IETF. GnuPG decided they know better than all other > stakeholders but apparently were also not able to convince the other > stakeholders that they had better technical arguments. > > When the WG, through rough consensus decided that the right way to deal > with the evolution of the OpenPGP standard did not match exactly what > the GnuPG maintainer wanted they decided to isolate themselves and > become incompatible with the rest of the world. (for > It is their choice and they are fully free to do that, but that does > not mean we need to follow it, or re-litigating their choice over and > over. > > We need to use standards for interoperability, and OpenPGP is a > *standard* debated and resolved the proper way. (It also bears pointing out that the majority that *was* able to reach rough consensus *included Proton*. If you don't wish to support their choices of PGP implementation technicalities, perhaps you should reconsider your email provider of choice?) > > --- > > A bit offtopic, but I am *extremely* curious. Simo, could you > please tell me why DMARC is failing from RedHat domains? Do you > know who/what's responsible? I suspect that you would have an > answer, considering that you have discussed DKIM on the ITEF > mailing list. > Since you're asking this, I wonder how much experience you have working in IT in large organizations. Specifically, I wonder so because in an organization of Red Hat's size, it's unlikely that Simo, a software engineer, would be directly involved in email operations, much less the *specific issue with Fedora mailing list* software & servers not playing well with Red Hat's email security settings. As noted in the infra ticket you link below, a fix is available upstream, but likely owing to the fact that the Fedora Project is composed of many individuals *voluntarily* contributing their time and not always being paid for the same, it has not yet been packaged or deployed for the specific use case and server at issue. > https://mailarchive.ietf.org/arch/msg/openpgp/BNlpN_YFVd7KeFQ3w-SFuojSLUE/ > > https://forge.fedoraproject.org/infra/tickets/issues/12487 > > I don't know how RedHat is organized, however, since this issue > has been discussed for almost a year, it is near inexcusable that > this is still an issue. Is this your responsibility, or is it the > responsibility of an email infrastructure team at RedHat, or > Fedora? The exact Fedora infra ticket you've linked above answers this question. It strikes me that you seem to have not commented on this > issue, and that you suddenly appeared, only to throw GnuPG under > the bus. > See my note above. While I believe that it's, at the very least, unfortunate that this issue has not yet been resolved (on this we may find some common ground), we're talking about large organizations with people of different foci being very spread out from each other, and your line of argument is seemingly trying to assert that an apple is responsible for oranges. Finally, as discussed above and earlier in this thread, when it comes to any perceived "throwing under the bus" of GnuPG, if blame is to be laid, the only people to blame for this would be the GnuPG developers themselves. > > Sent with Proton Mail secure email. > > On Monday, July 20th, 2026 at 17:26, Simo Sorce <[email protected]> wrote: > > > On Mon, 2026-07-20 at 20:48 +0000, CS Sushi Man via devel wrote: > > > I'm unaware of this consensus, and I'm also unaware of the > > > implications the decisions made by the OpenPGP WG may have in the > > > future. Could you tell me the specifics of these protocol changes, > > > and why LibrePGP is the responsible party? I'd rather have > > > the criticisms being made by the LibrePGP team *be addressed,* > > > rather than have them be ignored, and swept under the rug. > > > > > > https://gnupg.org/blog/20260320-some-criticism-matter.html > > > > > > I'd also like to see what the OpenPGP WG has to say about > > > LibrePGP, and again, *address* the concerns of the LibrePGP > > > maintainers. In particular, since you are on the RHEL crypto team, > > > why don't you lead this discussion? > > > > I have no reason to rehash pubic knowledge, if you are curious you can > > go here: https://datatracker.ietf.org/wg/openpgp/documents/ and read > > the documents and the mailing list threads. > > > > I am not sure why the link above matters at all. The "LibrePGP > > maintainers" had a voice in the OpenPGP WG like everyone else. > > > > OpenPGP is a standard, the standard is discussed and negotiated and > > agreed in IETF. GnuPG decided they know better than all other > > stakeholders but apparently were also not able to convince the other > > stakeholders that they had better technical arguments. > > > > When the WG, through rough consensus decided that the right way to deal > > with the evolution of the OpenPGP standard did not match exactly what > > the GnuPG maintainer wanted they decided to isolate themselves and > > become incompatible with the rest of the world. > > > > It is their choice and they are fully free to do that, but that does > > not mean we need to follow it, or re-litigating their choice over and > > over. > > > > We need to use standards for interoperability, and OpenPGP is a > > *standard* debated and resolved the proper way within a super-partes > > body called IETF. LibrePGP can be called a specification, but it is not > > an interoperable standard governed by a proper standardization body, > > therefore we can't rely on it going forward. It is that simple. > > > > Best, > > Simo. > > > > -- > > Simo Sorce > > Distinguished Engineer > > RHEL Crypto Team > > Red Hat, Inc > > > > -- > -- > _______________________________________________ > devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/[email protected] > Do not reply to spam, report it: > https://forge.fedoraproject.org/infra/tickets/issues/new >
-- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
