Hi, Jakub.

On 11/05/2026 16:21, Jakub Jelen - jjelen at redhat.com (via freepg
list) wrote:
> I find the update of the default gnupg2 package to freepg 2.5.x as one
> possible solution. That should prevent users to generate incompatible
> certificates (at least out of the box) and let them create librepgp
> artefacts when explicitly requested. But it will not make it compatible
> with the standardized OpenPGP artifacts.

Downstreams will eventually have to update to 2.5.x given that upstream
seems impatient to abandon support for 2.4.x and backporting security
fixes will soon become untenable.

We were hoping to be able to support type 35 ML-KEM encryption subkeys
in freepg, since these are explicitly permitted in v4 [1], however this
will involve significant development effort which nobody has yet had the
time (or budget!) to undertake.

Supporting v6 and SEIPDv2 artifacts in freepg is probably infeasible,
since these would require deep changes to gnupg code that would turn
freepg into a full fork.

Thanks,
Andrew.

[1]
https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-pqc-17#name-key-version-binding