Get rid of GnuPG dependency?

[handpickencounter]

There is an audited GPG rust library which could be used to get rid of the GnuPG dependency.

https://github.com/rpgp/rpgp

[marcos-morar]

I strongly believe that continuing to use GnuPG as the backend rather than switching to rpgp is the best approach.

GnuPG, with over 25 years of proven reliability, fully implements the OpenPGP standard and provides features like advanced key management, hardware token integration, and seamless compatibility with existing OpenPGP tools, which are essential for a reliable user experience.

While rpgp is a less mature, low-level library that lacks GnuPG’s comprehensive higher-level functionality, potentially requiring significant development to match. Additionally, rpgp’s limited adoption and reported build complexities could introduce stability risks for GpgFrontend users.

I think the right approach is optimizing GnuPG’s integration while preserving its proven ecosystem and user trust.

[handpickencounter]

GnuPG doesn't support openpgp v6.

Regarding "25 years of proven reliability": https://app.opencve.io/cve/?vendor=gnupg

Why does this read like a PR statement?

[handpickencounter]

There is also another more mature rust pgp project: https://gitlab.com/sequoia-pgp/sequoia

[saturneric]

Thanks for bringing this up! To be honest, the idea of a “GnuPG replacement core” has been in my mind ever since I started this project, but I never really took the first step — and for years nobody else suggested it either. So I find it interesting that it’s being raised now.

From my perspective, though, GnuPG can’t simply be replaced. It’s not just a crypto library, it’s a whole ecosystem: key storage, gpg-agent, pinentry, smart card support… all the things that save me (and other developers) a huge amount of work. On top of that, GnuPG has been tested for decades and supported by commercial users, which gives it a level of trust and reliability that new libraries can’t easily match.

That said, I also see the downsides: the codebase is old, sometimes diverges from the OpenPGP spec, and isn’t the easiest to maintain or extend. That’s why projects like rpgp, gopenpgp, or Sequoia are worth keeping an eye on. Personally, I think gopenpgp feels more practical right now than rpgp, since it’s already used in production and has a simpler interface.

The way I see it, the future of GpgFrontend is not about “replacing” GnuPG, but about adding optional backends alongside it. GnuPG will stay the primary backend, but we could experiment with something like gopenpgp for lightweight use cases or testing. That way we get the best of both worlds without losing the stability and ecosystem GnuPG gives us.

[handpickencounter]

Sequoia actually has a drop-in replacement mode for GnuPG: https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg

[saturneric]

Sequoia actually has a drop-in replacement mode for GnuPG: https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg

Since GpgFrontend only talks to the backend via GPGME, in principle users can just replace gpg with chameleon-gnupg and it should work, as long as the compatibility layer fully covers the needed commands (--status-fd, --with-colons, gpg-agent, pinentry, etc.).

So from GpgFrontend’s side, there’s nothing special to implement — it’s more about how complete Sequoia’s drop-in replacement is. If you test it successfully, feel free to share the results here!

[marcos-morar]

GnuPG doesn't support openpgp v6.

Regarding "25 years of proven reliability": https://app.opencve.io/cve/?vendor=gnupg

Why does this read like a PR statement?

Thank you for raising the point about GnuPG’s lack of OpenPGP v6 support, I hadn’t considered this, and it’s a valid concern.

Among other things, OpenPGP’s v6 work on post-quantum cryptography, supported by Proton and Germany’s BSI, prioritizes open-standard PQC algorithms, which is more trustworthy than NIST’s PQC standards. GnuPG’s reliance on NIST-aligned PQC in its upcoming V2.6 may thus lag in reliability for future-proofing.

That said, I’m not affiliated with GnuPG. my view stems from its 25+ years of battle-tested reliability and widespread use, which the CVE list you shared actually underscores, extensive testing by a large user base surfaces and resolves vulnerabilities over time, strengthening the software. Switching to rpgp, while promising for v6 compliance, carries risks due to its relative immaturity and narrower adoption. Until rpgp or another alternative matures and undergoes rigorous, independent audits by trusted entities, GnuPG’s proven ecosystem remains a safer choice for GpgFrontend’s stability and compatibility with existing workflows.

[handpickencounter]

There aren't real problems with NIST's PQC standards, just some sour grapes grown by one of the losing team's members. Kyber is fine, or at least there is no scenario where it gets broken and NTRU survives.

Switching to rpgp, while promising for v6 compliance, carries risks due to its relative immaturity and narrower adoption

Safe Rust allows for far more latitude than C, you only have to worry about logic errors instead of worrying about copy pasting some text and compromising your entire system. And there aren't that many degrees of freedom in a system like openpgp, as long as the tests pass you are good to go.

Keep in mind that OpenPGP in general is rather lame due to all the baggage and wizardry that went into it for 25 years, its only usefulness comes from its popularity. You are far better off using age with SSH keys and signatures than PGP, but few know this and are comfortable with the CLI tooling to do this. We should focus on harm mitigation and abandoning a C code base is one such.