#librepgp — Public Fediverse posts

I have been dragged into the rabbit hole of GnuPG/LibrePGP VS Sequoia/OpenPGP and, boy it is ugly. Yeah, yeah, I know, PGP is bad, but of all the ugly things that could have happened to the FOSS crypto space, this is really unwelcome. I wish people would just sit at a table and talk.

#pgp #gpg #sequoia #crypto #cryptography #security #foss #floss #libre #drama #ietf #privacy #openpgp #librepgp

Post-quantum defaults and GnuPG

@andrewg email is a very insightful overview of where the standards, implementations, and openness of the community.

After years of using OpenPGP, the PQC discussions are a good opportunity to rethink what we should prepare for next and especially which community we should work with.

#pgp #librepgp #openpgp #opensource
#community #cybersecurity

🔗 https://lists.gnupg.org/pipermail/gnupg-users/2026-April/068280.html

@ber @GnuPG @rob Thanks! I'll point the lurkers to the mailing list for my full response, which I agree is better in long form: https://lists.gnupg.org/pipermail/gnupg-users/2026-April/068288.html

The tl;dr though is simple: the burning issue is a power struggle between a collective governance model (#OpenPGP) and a BDFL governance model (#LibrePGP). There isn't room for both. And while we can all try to be more civil, calling out bad behaviour will always have the appearance of incivility.

When looking at the changes towards the new 2.5.19 version of #GnuPG, there are many small things; like a way to use OCB for symmetric-only encryption, a few defect fixes and improvements.

Not that exciting, but maintenance of the well known #LibrePGP, OpenPGPv4 and CMS capable crypto engine.... you may want to know anyhow. ;)

https://lists.gnupg.org/pipermail/gnupg-announce/2026q2/000504.html
https://dev.gnupg.org/T7998

#GnuPG #EndtoEndCrypto #FreeSoftware

Dear GnuPG packagers and builders, please upgrade libgcrypt to v1.12.2 to remove a denial of service vulnerability (estimated CVSS 3.1: AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H -- 7.5 (HIGH)) Releases of other stable versions of libgcrypt are available as well.

(GnuPG versions >= 2.5.7 are not affected due to the use of a different encryption API.)

See https://lists.gnupg.org/pipermail/gnupg-announce/2026q2/000503.html for details.

#GnuPG #EndtoEndCrypto #FreeSoftware #LibrePGP

Details about the (ongoing) response to https://gpg.fail/ from GnuPG's side:

* https://www.gnupg.org/blog/20251226-cleartext-signatures.html
* https://dev.gnupg.org/T7906 Memory Corruption in ASCII-Armor Parsing
* https://dev.gnupg.org/T7900 (overview)

Please upgrade to GnuPG 2.5.16, 2.4.9 or #Gpg4win 5.0.0-beta479 which already have the fix for what (currently) is seen to be the only major defect: T7906.

(Researchers - Thanks! - found defects in GnuPG, Sequoia-PG, Minisign and age.)

#EndtoEndCrypto #LibrePGP #GnuPG #Security

#GnuPG v2.5.14 is here to try.

A no-brainer upgrade for those who use the 2.5 series already. You'd get some defects fixed and a new secret key export-import for the Post quantum cryptography (#PQC) algorithm "Kyber". RCF8332 for ssh is now supported.

For others: the 2.5 series is good for Windows 64 and PQC. #LibrePGP #OpenPGPv4 #EndtoEndCrypto

https://lists.gnupg.org/pipermail/gnupg-announce/2025q4/000499.html

@Velocifyer @andrewg That's the reason for my plans to switch from #GnuPG to #sequoiapgp, not the #LibrePGP vs #RFC9580 mess. If a RTFM doesn't suffice and it comes down to RTFC (...Code), I am out.

See GnuPG manpage:

❯ gpg --version | head -n 1
gpg (GnuPG) 2.5.13
❯ man gpg | sed -n '/^[[:space:]]*dane/,/^$/p'
              dane   Locate a key using DANE, as specified in draft-ietf-dane-openpgpkey-05.txt.

... and:

The lookup result MUST pass DNSSEC validation; if validation reaches any state other than "Secure", the verification MUST be treated as a failure.

Source: https://datatracker.ietf.org/doc/html/draft-ietf-dane-openpgpkey-05#section-5

@keys_openpgp_org @upofadown #LibrePGP is, for me, the Office Open XML of the #PGP world.

Ktoś powinien zrobić diagram.

#PGP (Pretty Good Privacy) to oryginalne, własnościowe narzędzie. Z niego wyprowadzono otwarty standard #OpenPGP. Ten standard zaimplementowano w #GPG (GNU Privacy Guard), którego autorzy przejęli rozwój standardu, do momentu, w którym stwierdzili, że nie dogadają się ze współautorami, i sforkowali go do #LibrePGP. Następnie GPG sforkowano jako #FreePG, żeby przywrócić zgodność z OpenPGP.

Someone needs to make a flowchart for this.

#PGP (Pretty Good Privacy) is the proprietary tool. The open standard developed from it is called #OpenPGP. This standard was implemented by a tool called #GPG (GNU Privacy Guard), who took up the development of the standard, until they've decided they don't like where others are pushing it, so they've forked the standard into #LibrePGP. Then GPG was forked into #FreePG to bring it back to OpenPGP compliance.

@DD9JN ... and #GnuPG v2.5.13 is a production ready version with improvements for PQC encryption and Windows.

This version comes with a few smaller security improvements over the previous release, and reduces problems if several applications use GnuPG as crypto engine in the background.

#OpenPGPv4 #LibrePGP #EndtoEndCrypto #FreeSoftware

@mgorny The #OpenPGP situation is really sad especially because there is no alternative in sight.
This was also the topic of the round table discussion in the #GentooWorkshop 2025-06-14. Dear community, what do you think? Would you like another meeting to discuss #LibrePGP, #Sequioa-pgp and #GnuPG? Just let us know.
https://gentoo-ev.org/news/online-workshops-2025/

@mgorny Thanks for planning to bring up my bug (https://bugs.gentoo.org/963069) for discussion in the council. I personally use OpenPGP with all bells and whistles, but agree that what happens lately (#LibrePGP vs #RFC9580) is a s**tshow, and #OpenPGP was never easy to use. When it comes down to it, we should think about what the main use of OpenPGP at Gentoo is. And, that's signing commits if I am not mistaken. If #RFC9580 and #LibrePGP folks can't reach an agreement, I hope that #Git gets some logic implemented that allows it to automatically delegate the task of v5 (LibrePGP) or v6 (RFC9580) signature verification to the correct OpenPGP tool. In that case, users are free to choose the tool of their choice for Git commit signing.

No to poprawcie mnie, jeżeli się mylę, co do aktualnego stanu #OpenPGP.

Po pierwsze, jest dawne #RFC4880bis, aktualnie przepychane jako "#LibrePGP", używane przez #GnuPG (i #rnp?), z formatem kluczy "v5" — i zdaje się, że każdy inny projekt spogląda na to z politowaniem.

Po drugie, jest #RFC9580 z formatem kluczy "v6", używany przez #OpenPGPjs, #SequoiaPGP (i inne narzędzia), ale odrzucony przez GnuPG. I wygląda na to, że jest przepychane z założeniem, że GnuPG ugnie się pod presją.

Więc mamy dwa niezgodne ze sobą standardy, ze "wspólnym mianownikiem" w postaci zabytkowego #RFC4880; jedne narzędzia przepychają jeden standard i ignorują drugi, a inne decydują się wspierać oba, by pomóc swoim użytkownikom. A #Gentoo ostatecznie utknie z tym, co wspierać będzie GnuPG, bo potrzebujemy kryptografii, która działa na wszystkich wspieranych platformach, a nie tylko tam, gdzie Rust.

https://bugs.gentoo.org/963069

Okay, so please correct me if I'm wrong about the state of #OpenPGP right now.

So first there's the former #RFC4880bis which is now pursued as "#LibrePGP", used by #GnuPG (and #rnp?), with a "v5" key format, that everyone else seem to looks "politely" at.

Then there's #RFC9580 with a "v6" key format, used by #OpenPGPjs, #SequoiaPGP (and more) but explicitly rejected by GnuPG. However, it seems to be pushed forward under the assumption that GnuPG will yield to pressure.

So we effectively have two incompatible standards, with a "common denominator" of ancient #RFC4880, some tools pursuing one of them with disregard for the other, and a few supporting both for the sake of the users. And #Gentoo is effectively stuck with whatever GnuPG supports, because we need working crypto on all supported platforms, not just the "Rust subset".

https://bugs.gentoo.org/963069

Back from the summer, #GnuPG 2.5.12 is now ready for production usage.
And this includes the post-quantum cryptography encryption (#PQC) support which is the main feature of the 2.5 series. (Okay, there is also better support for 64bit Windows.)

So give it a spin or point your favourite GNU/Linux distribution to it for packaging.

https://lists.gnupg.org/pipermail/gnupg-announce/2025q3/000497.html

#EndtoEndCrypto #LibrePGP #OpenPGPv4
#FreeSoftware

Also updated my work OpenPGP/GPG keys to ECC.

I've had GPG keys since 1998.
One day, I will get an encrypted message...

One day...

#openpgp #gpg #gnupg #librepgp #encryption

Retiring the RSA-version of my OpenPGP/GnuPG key, to be replaced by ECC. Just need to do some CLI trimming on my keyring. :)

#encryption #openpgp #gpg #gnupg #librepgp

#PGP bzw. genauer #OpenPGP gibt es in verschiedenen Standards:
- RFC 2440
- RFC 4880
- RFC 9580 und
- LibrePGP

Johannes Roth und Falko Strenzke haben die Unterschiede zwischen den wichtigsten Standards herausgearbeitet:
https://github.com/crypto-security-tools/OpenPGP-LibrePGP-comparison

#rfc2440 #rfc4880 #rfc9580 #librepgp

#GnuPG's "public testing release series" has a new version 2.5.7.

https://lists.gnupg.org/pipermail/gnupg-announce/2025q2/000493.html

Remember:

* It is for you, if you want to test the new
post-quantum cryptography (PQC) features
or the 64 Bit Windows support.

* The series features Kyber (FIPS-203) as PQC encryption algorithm.

A new Gpg4win 5 Beta is forthcoming in the next days.

Technical details: https://dev.gnupg.org/T7671

#LibrePGP #OpenPGPv4 #EndtoEndCrypto

@hko @sovtechfund Was die Akteure bei OpenPGPv6 angeht, da sind mindestens g10code und Ribose zu nennen, dass sind zwei Organisationen. Andere haben versucht was zu retten oder sich zurückgezogen.

#LibrePGP ist aus meiner Sicht eigentlich der lange notwendige und vereinbarte nächste Schritt für OpenPGP (also OpenPGPv5 wenn Du so willst). Da das die meisten im Einsatz befindlichen Produkte nutzen, wohl auch der eigentliche Standard.

So gesehen wäre OpenPGPv6 von der IETF der eigentlich "Fork"

@Gerbsen @qbi @sovtechfund Aus meiner Sicht nur leider an den falschen Stellen. Ich finde es sehr gut, dass versucht wird da grundsätzlich was zu tun. Aber Zielrichtung und Ergebnisse fand ich teilweise fragwürdig.

Das bekomme ich im Fediverse kaum unter. Die Spitze des Eisberges ist https://www.gnupg.org/blog/20250117-aheinecke-on-sequoia.html - meiner Ansicht nach hat das Geld vom STF den Frust mit ermöglicht. Auch, dass es jetzt zwei vorgeschlagene Standards gibt #LibrePGP und #OpenPGPv6. https://librepgp.org/

The March release for #GnuPG in the PQC public testing release series is here: v2.5.5 only has a few fixes, but those seem important ... removing potential "hangs" 🧐 on windows and elsewhere.

https://dev.gnupg.org/T7530
https://lists.gnupg.org/pipermail/gnupg-announce/2025q1/000491.html

#FreeSoftware #EndtoEndSecurity #LibrePGP #OpenPGPv4

Better handling of certificates and public keys
with #Gpg4win v4.4.0's improved crypto manager _Kleopatra_.

It also comes with #GnuPG v2.4.7 for Windows. Workflows that profit from several signatures on a file
profit as well.

https://gpg4win.org/version4.4.html <-- see what else is new.

#LibrePGP #OpenPGPv4 #EndtoEndCrypto #FreeSoftware

Le slide dell’intervento “(Open|Libre)PGP - Novità, controversie e sviluppi futuri” proposto ad HackЯocchio 2024

https://www.fabriziotarizzo.org/documenti/slide-openpgp-2024/

#OpenPGP #LibrePGP #RFC9580 #hackrocchio

#GnuPG 2.4.6 is available. Accumulated fixes and small improvements over the last 7 months. There is even a new tool `gpg-mail-tube` to encrypt an email automatically in a pipe. Give it a try, especially if you use hardware tokens.

https://lists.gnupg.org/pipermail/gnupg-announce/2024q4/000486.html

https://dev.gnupg.org/T7030

#FreeSoftware #EndtoEndSecurity #OpenPGP #LibrePGP

In case you are asked about a downgrade attack on #gnupg ,#librepgp, or *#pgp you may want to point to my comment over at

https://lists.gnupg.org/pipermail/gnupg-users/2024-August/067270.html

In recent weeks, a theoretical downgrade attack against the new default encryption mode used by GnuPG 2.5 has been published. This comes two years after a theoretical downgrade attack was announced against GnuPG's new default *signature* format. Both issues have been addressed in the latest update to the official OpenPGP specification, but GnuPG has declared that it will not implement the fixes.

#gnupg #openpgp #librepgp

https://blog.pgpkeys.eu/security-issues-librepgp-2024-08.html