Question on Integrity of Sequoia-PGP Developers
Robert J. Hansen
rjh at sixdemonbag.org
Thu Sep 11 07:29:14 CEST 2025
> I am now aware there has been a split between the GNUPG and Sequoia-
> PGP developers.
I'm not a GnuPG developer, just a long-time community observer.
There is a *lot* of stuff between the Sequoia and GnuPG devs that's
hidden from public view. I don't mean that as "they're hiding stuff from
us" -- I don't think that's true at all -- but more "they keep their
disagreements private for the benefit of the community as a whole,"
which is probably a good policy.
> Apparently they wanted GNUPG to be more secure, robust, and usable
> in a way the GNUPG developers did not agree with.
This appears to be incorrect.
Engineering is all about tradeoffs. GnuPG embraces a different set of
tradeoffs than Sequoia. That's the fundamental disagreement: it's not
about security, robustness, or usability. It's about the tradeoffs the
developers are willing to make to achieve those things.
GnuPG came out in 1999, and some of those decisions from 1999 are still
affecting its development today. Way back then, for instance, GnuPG
decided it would support RFC1991 ("Classic PGP"). This turned out to,
IMO, be a bad call: but now there are so many people dependent on GnuPG
for RFC1991 support that GnuPG can't fix the mistake without incurring a
lot of anger from the user base.
Sequoia, on the other hand, is a clean slate. They get to make entirely
new decisions about what behaviors they will support and which ones they
won't. And in twenty years, Sequoia will be beholden to decisions they
made long ago, too.
This is the nature of software.
> It seems there is a disagreement between GNUPG and Sequoia-PGP about
> the security of GNUPG. GNUPG claims making the changes the Sequoia-
> PGP developers wanted would risk people's safety in using it--
> especially the crypto-refresh.
Some years ago a major international bank asked me to join them on a
large engineering effort. Some consultant had told them that yes, their
COBOL infrastructure had been running for decades without a problem, but
sooner or later they weren't going to be able to hire COBOL programmers
any more: so, this consultant said, it's best if the entire financial
software system gets rewritten in Java, for ease of maintenance going
into the future.
When I heard this I immediately smiled, said "Nope!", stood up, and
walked out.
The bank looked at the risk of "maybe we can't hire COBOL programmers in
the future", and weighed it against the risk of "we will definitely
introduce tons of bugs in our first Java release, as opposed to the
COBOL codebase which is stable, mature, and quite boring." The bank
decided staying with COBOL would be the bigger risk.
I looked at the same problem, said "rewriting in Java is a much bigger
risk, and I'm not cool with this level of risk."
Which one of us was right? It's hard to say. It's a judgment call.
The Sequoia guys are free to make what judgment calls they wish. GnuPG
gets to make its own judgment calls, too. Just as the Sequoia guys think
the GnuPG guys are exercising bad judgment, the GnuPG guys think the
same of Sequoia.
> Despite GNUPG's disagreements Phil Zimmermann, Micheal Rysiek-
> Wozniak (former GNUPG endorser), and Debian now are using Sequoia-
> PGP.
Sure. I also am using librnp right now for my OpenPGP needs. That
doesn't mean I dislike GnuPG.
Sure, some people in the community are using Sequoia. That's good!
Competition is healthy. It doesn't mean those people have suddenly
decided GnuPG should be abandoned, or that it's an inferior product, or
anything else.
> What I am confused about is whether I can trust my privacy with the
> Sequoia Developers.
Never trust anyone who will tell you whom you should or should not trust.
Trust is too important a decision to outsource.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250911/686799b2/attachment.sig>
More information about the Gnupg-devel
mailing list