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.)
#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:
GnuPG
David Sardari❯ 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
OpenPGP is a message format for email (and file) encryption that lacks a standardized lookup mechanism to securely obtain OpenPGP public keys. This document specifies a method for publishing and locating OpenPGP public keys in DNS for a specific email address using a new OPENPGPKEY DNS Resource Record. Security is provided via DNSSEC.
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.
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.
Jezus Michał "Le Wzdych" (on)
Jesus Michał "Le Sigh" 🏔 (he)
Gentoo e.V.