You are beating a dead horse, these discussions already happened, the fact you did not follow the events does not mean everyone else needs to rehash everything for you, and get dragged in an endless discussion again.
This split was neither nice nor helpful but ultimately we follow the IETF Working Group standard, this was decided a while back when we moved the RPM verification to use the sequoia library. Rehashing those discussions again now serves no purpose and is just a waste of time and distracting from this change proposal. If you are "curious" please go and source the material you have already been pointed to and use a search engine or an AI to further summarize the matter until you are satisfied. But please stop insinuating that people here are somehow nefariously joining a cabal of anti-gnupg sentiment. That is not the case and it is not relevant to the current discussion anyway. People here already gave you reasonable answers for why this happened, and roughly how it went down. That is more than sufficient for the purposes of this change proposal discussion. Best, Simo. On Tue, 2026-07-21 at 15:37 +0000, CS Sushi Man via devel wrote: > I find this habit of throwing the GnuPG developers under the bus, > and assigning significant blame to them, very odd, and it is why I > sided with them in the first place. I don't like it *one bit.* > > To me, the discussions that lead to the draft which was rejected > by GnuPG, still seem very clandestine. The GnuPG developers were > talking about *real-world* usage, like within Thunderbird, for > instance, and how this new draft *broke* compatibility. The WG was > *not* talking about real-world use cases. So, why would the GnuPG > engineers create a new standard, broken away from the WG, and cause > all of this fragmentation, if they *didn't* have technical > standing? Are you implying that the GnuPG developers are not *real* > engineers? Why would they suddenly cause this schism, after I'd > guess almost a *decade* of there not being a schism? > > From an outside observer, this looks *really bad* for the side of > the WG specification designers. The GnuPG developers have raised > points regarding half-truths. It seems to me that many proponents > of the WG's standard, have been raising half-truths. I *also* see > many half truths being raised within other technical discussions, > and I *don't* like them whatsoever. > > Stop throwing GnuPG under the bus. It is destroying the WG's > position, in my opinion. And again, I don't disagree with the > proposal that we should switch to an OpenPGP tool. I'm just trying > to figure out what on earth happened here previously, because it is > *weird.* And I'm afraid that it may happen again, to other > committees... I wouldn't have even been inclined to dig through > GnuPG/IETF's mailing list archives, if GnuPG was *not* thrown under > the bus in this manner. > > It is weirder that many seem insistent on *not* talking about > what actually happened here, and to rehash points about how > everything is the GnuPG developer's fault. You're saying that these > things are *not* for discussion, yet you state that GnuPG is the > responsible party. Which one is it? > > To me, this event, and *this discussion,* just *doesn't* make > sense, unless I surmise that something far more *sinister* is > occurring here, than how it appears on the surface. > > One of the LWN links listed by Julian, appears to denote a RedHat > engineer deliberately withholding updates to a GnuPG package, due > to "incompatibility" reasons. Whether that is a half-truth, or not, > may be left for debate, and interpretation. > > https://lwn.net/Articles/1055053/ > > The most important thing to note personally, is that it isn't > clear to me what exactly these incompatibility issues are. And > since it would likely take a great amount of time for me to become > a cryptography expert, it isn't *really* feasible for me to know > personally. However, I'm still more inclined to trust the GnuPG > developers in this case, since they have stated *real-world* > incompatibility issues within their emails. This is the primary > reason why I'm biased towards them. > > Considering that RedHat emails are still failing DMARC after a > whole *year,* and that others appear to be defending RedHat on the > email issue, I now have the inclination to *not* trust RedHat > engineers' opinions. > > I urge *everyone* to dig through, and come to your own > conclusions here. This event is *very* significant, and it may > foretell *future* events. > > I won't make further emails regarding this topic. I've said what > needed to be said. > > > Sent with Proton Mail secure email. -- 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
