The PGP problem (2019)

New vulnerabilities and project responses

• Thread resurfaces the article due to recent CCC “gpg.fail” issues.
• GnuPG is criticized for declaring some serious bugs “out of scope”/WONTFIX; others are patched but not yet widely shipped.
• Minisign and age were also affected by some findings, but minisign’s issue is described as much less severe and quickly fixed; the age issue was a simple path-sanitization bug, not cryptographic.
• Several comments stress that the key security criterion is how maintainers handle bugs, not bug-free code; age’s use of Discord as a primary contact is seen as a bad look.

Replacing PGP/GnuPG: practicality and use cases

• Many agree age + minisign provide a cleaner stack that covers common needs (file encryption, signing, backups, commit signing), but ecosystem support (e.g. Git forges) lags.
• One recurring theme: PGP is hard to get rid of because distros and tooling assume it; shipping minisign by default is suggested to break the chicken-and-egg problem.
• Some users note PGP’s flaws feel “esoteric” compared to their modest threat models; for them, migration pain outweighs theoretical benefits.

Web of Trust, key discovery, and centralization

• Web of Trust is called “security theater” by some; others point to new designs based on key transparency logs rather than WoT.
• Keyservers are argued to have mostly “solved” simple key distribution, though modern efforts try to make this auditable and extensible (e.g., auxiliary data for age/minisign/SSH keys).
• Debate over centralization: one side says E2EE should make server trust irrelevant; the other emphasizes availability and censorship (centralized systems can be blocked, e.g., Signal in some countries).

Sequoia and “modern” OpenPGP vs moving on

• Some argue the article mostly attacks GnuPG, not PGP, and promote Sequoia (Rust, modern crypto, AEAD, Argon2, PQC) as a sane OpenPGP implementation.
• The counterargument: once you use new features that break compatibility with most existing PGP clients, you’ve sacrificed the main remaining benefit (interoperability), so you may as well adopt non-PGP tools.
• There’s disagreement over whether OpenPGP’s 1990s design is “dangerous and antiquated” or merely ugly but serviceable.

Alternatives and their downsides

• Suggested replacements: Signal (messaging), age (file encryption), minisign/ssh/Sigstore (signing), restic/gocryptfs/age for backups, magic-wormhole for ad‑hoc file transfer.
• Critiques: some are centralized, require phone numbers, or depend on proprietary infrastructure; availability under blocking and lack of distro integration are concerns.
• Signal specifically is debated: its cryptography and clients are said to be open source and solid, while others highlight MobileCoin, broken reproducible builds, Google dependencies, and a centralized, number‑tied model as trust and privacy issues.

Email, UX, and protocol design

• A major line of criticism is that encrypted email (with PGP) is structurally unsafe: users routinely break confidentiality by replying in plaintext, and the protocol doesn’t enforce secure behavior.
• Some insist this is a client/UI issue; others respond that any protocol relying on clients to “opt in” to security is broken by design.
• There’s also discussion of MDC/integrity handling (EFAIL vs gpg.fail), with disagreement over whether GnuPG’s error behavior is defensible or dangerously lax.

Complexity, simplicity, and real-world threat models

• GPG and OpenSSL are seen as huge, complex, and full of “footguns”; minisign/signify are praised for single‑algorithm simplicity (Ed25519) and small attack surface.
• Others report GPG “just works” for them and question whether the article’s examples (e.g., forwarded plaintext) justify abandoning a tool that appears to have resisted state-level adversaries in practice.
• Overall, the thread reflects a split: one camp pushing to abandon PGP in favor of narrowly scoped modern tools, another emphasizing PGP’s versatility, installed base, and acceptable security when carefully used.