FreePG now has a public mailing list for general discussion and formal decision-making.
Thanks to simplelists.com for their kind sponsorship!
FreePG maintains a shared patchset for #GnuPG downstream packagers to track, maintain, and apply commonly-used patches. The project goals are:
* Minimise divergence from the IETF #OpenPGP specification
* Support reading of LibrePGP artifacts for compatibility
* Fix security issues that remain unresolved upstream
* Support the maintenance needs of downstream distributions
| Homepage | https://freepg.org |
| Mailing List | https://openpgp.simplelists.com/freepg |
I set up a containerized build environment to facilitate working on the GnuPG IETF PQC branch:
https://codeberg.org/freepg/freepg-draft-ietf-openpgp-pqc/src/branch/main/build
The goal of adding #IETF #PQC support to @freepg is still very many steps away. But it's nice to have a foundation to start from :)
FreePG now has a public mailing list for general discussion and formal decision-making.
Thanks to simplelists.com for their kind sponsorship!
The https://freepg.org/ project maintains patches against #GnuPG with the goal of closer adherence to the IETF #OpenPGP spec.
One currently open question is if/how draft-ietf-openpgp-pqc support could be realistically added to #FreePG
I've started https://codeberg.org/freepg/freepg-draft-ietf-openpgp-pqc first of all as a notes-to-self repo for a (presumably very slow and long-term) side quest to explore this problem.
Specifically, the goal would be adding support for v4 ML-KEM-768+X25519 subkeys.
https://www.ietf.org/archive/id/draft-ietf-openpgp-pqc-17.html#ecc-mlkem
#GnuPG 2.5.18-freepg has been released.
It contains all the latest bug fixes from upstream GnuPG, plus the usual FreePG patches.
This release also contains fixes for additional gpg.fail issues that remain unfixed upstream:
* skip trust packets during import-restore (https://gpg.fail/trust)
* compat ignore truncated line (https://gpg.fail/formfeed)
* fail on unprintable armor headers (https://gpg.fail/nullbyte https://gpg.fail/notdash)
Note that the FreePG project considers the 2.5.x branch to be experimental, and does not enable non-standard OpenPGP algorithms unless “--compliance=gnupg” is explicitly set.
https://gitlab.com/freepg/gnupg/-/releases/gnupg-2.5.18-freepg
#GnuPG 2.5.17-freepg has been released.
It contains all the latest bug fixes from upstream GnuPG, plus the usual FreePG patches.
* This release contains a fix for a critical buffer overflow vulnerability in GnuPG >= 2.5.13 - see upstream's release notes for full details.
Note that the FreePG project considers the 2.5.x branch to be experimental, and does not enable non-standard OpenPGP algorithms unless “--compliance=gnupg” is explicitly set.
https://gitlab.com/freepg/gnupg/-/releases/gnupg-2.5.17-freepg
Kritik an GnuPG und seinem Umgang mit gemeldeten Lücken
Die auf dem 39C3 demonstrierten Probleme in der PGP-Implementierung GnuPG riefen vielfältige Kritik an GnuPGs Umgang damit, aber auch an PGP insgesamt hervor.
#ChaosCommunicationCongress #IT #OpenPGP #PGP #Verschlüsselung #news
#GnuPG 2.5.16-freepg has been released.
It contains all the latest bug fixes from upstream GnuPG, plus the usual FreePG patches.
Note that the FreePG project considers the 2.5.x branch to be experimental, and does not enable non-standard OpenPGP algorithms unless “--compliance=gnupg” is explicitly set.
https://gitlab.com/freepg/gnupg/-/releases/gnupg-2.5.16-freepg
#GnuPG 2.4.9-freepg has been released.
It contains all the latest bug fixes from upstream GnuPG, plus the usual FreePG patches.
In addition, a fix for the default filename path traversal issue identified by #gpgfail has been backported from upstream 2.5.16 (https://gpg.fail/filename)
https://gitlab.com/freepg/gnupg/-/releases/gnupg-2.4.9-freepg
@upofadown If you want to talk about "vindictive incompatibility", a better example of that is the absolutely bizarre decision of #GnuPG to break away from https://datatracker.ietf.org/doc/draft-ietf-openpgp-pqc/
GnuPG forked that draft with barely a pretense of an actual reason, and is now seemingly trying to speedrun a rollout of that incompatible non-IETF #PQC format (including by apparently trying to nudge people to switch to the 2.5.x series by avoiding tagging new releases in the 2.4 series)

This document defines a post-quantum public key algorithm extension for the OpenPGP protocol, extending [RFC9580]. Given the generally assumed threat of a cryptographically relevant quantum computer, this extension provides a basis for long-term secure OpenPGP signatures and ciphertexts. Specifically, it defines composite public key encryption based on ML-KEM (formerly CRYSTALS-Kyber), composite public key signatures based on ML-DSA (formerly CRYSTALS-Dilithium), both in combination with elliptic curve cryptography, and SLH-DSA (formerly SPHINCS+) as a standalone public key signature scheme.