Please note that GnuPG 2.2 is also end of life now.
https://gnupg.org/download/index.html
On Sat, 04 Jan 2025 08:42:10 +0000
Stephan Verbcheln <verbuecheln@posteo.de> wrote:
Please note that GnuPG 2.2 is also end of life now.
https://gnupg.org/download/index.html
GnuPG 2.4.7 is in experimental[1] but neither yet in sid[2] or trixie[3] (where it is version 2.2.45-2 in both repositories). The trixie freeze timeline is not yet announced[4] but compared to bookworm[5] one might
guess this will happen in the near future.
Is there enough time to shift GnuPG 2.4
into trixie until the planned summer release?
[1] https://packages.debian.org/experimental/gnupg
[2] https://packages.debian.org/sid/gnupg
[3] https://packages.debian.org/trixie/gnupg
[4] https://release.debian.org/testing/freeze_policy.html
[5] https://release.debian.org/bookworm/freeze_policy.html
I believe this would be good, I frequently run into GnuPG bugs in the
2.2.x branch that was fixed years ago in 2.4 and today I mostly these on Debian because others moved on to 2.4.x. Andreas, can you give a
current status of pending issues for experimental->unstable upload?
On 2025-01-07 Simon Josefsson <simon@josefsson.org> wrote:
[...]
I believe this would be good, I frequently run into GnuPG bugs in the
2.2.x branch that was fixed years ago in 2.4 and today I mostly these on
Debian because others moved on to 2.4.x. Andreas, can you give a
current status of pending issues for experimental->unstable upload?
Hello,
... guessing I might be the Andreas in question ...
Afaik there is no /known/ blocker except for the libgnupg-interface-perl
test error #1088155.
Should we move to 2.4? 2.4 is not a LTS release and will also EOL in
trixie' soon (2026-06-30).
2.6 will be the next LTS release. It has not yet been declared stable
and definitly is an implementation of librepgpg instead of the RFC
blessed version.
cu Andreas
On 2025-01-07 Simon Josefsson <simon@josefsson.org> wrote:
[...]
I believe this would be good, I frequently run into GnuPG bugs in the
2.2.x branch that was fixed years ago in 2.4 and today I mostly these on Debian because others moved on to 2.4.x. Andreas, can you give a
current status of pending issues for experimental->unstable upload?
Hello,
... guessing I might be the Andreas in question ...
Afaik there is no /known/ blocker except for the libgnupg-interface-perl
test error #1088155.
Should we move to 2.4? 2.4 is not a LTS release and will also EOL in
trixie' soon (2026-06-30).
On Tue, Jan 07, 2025 at 07:01:51PM +0100, Andreas Metzler wrote:[...]
Should we move to 2.4? 2.4 is not a LTS release and will also EOL in
trixie' soon (2026-06-30).
I haven't been fully following the GnuPG situation, but did the
situation where 2.4 would generate v4 keys that weren't fully compatible
with the wider ecosystem get solved? Is the patch RedHat et al are
carrying sufficient for that?
I believe this would be good, I frequently run into GnuPG bugs in the
2.2.x branch that was fixed years ago in 2.4
Andreas, can you give a current status of pending issues for experimental->unstable upload?
It seems there is push from the anti-GnuPG people to promote a fork
called FreePG instead of real GnuPG, will you package that?
https://gitlab.com/freepg/gnupg
If so I think there would be value in having the real GnuPG as a
separate Debian package, for those who want to use the real version.
GnuPG 2.4 was released in 2022, long before the LibrePGP schism. It is generally not clear to me how the divergence from upstream is a reason
to favor 2.2 over 2.4, except that patches have to be ported (once?).
I also do not understand what is wrong/lacking with the already patched versions in Experimental and Ubuntu.
https://packages.debian.org/experimental/gnupg
On Thu 2025-01-09 07:55:36 +0100, Stephan Verbücheln wrote:
GnuPG 2.4 was released in 2022, long before the LibrePGP schism. It
is generally not clear to me how the divergence from upstream is a
reason to favor 2.2 over 2.4, except that patches have to be ported (once?).
sadly, 2.4 was released at a time when the LibrePGP schism was on the horizon,
For example, OpenPGP certificates produced by earlier versions of 2.4
and imported into Thunderbird advertised non-standardized encryption mechanisms that Thunderbird didn't support, which led to unreadable
mails for those users.
That's why we delayed bringing 2.4 into debian, so that our users
wouldn't get locked into non-standard or suboptimal cryptographic
mechanisms.
GnuPG 2.4 was released in 2022, long before the LibrePGP schism. It is generally not clear to me how the divergence from upstream is a reason
to favor 2.2 over 2.4, except that patches have to be ported (once?).
I also do not understand what is wrong/lacking with the already patched versions in Experimental and Ubuntu.
https://packages.debian.org/experimental/gnupg
https://packages.ubuntu.com/noble/gnupg https://packages.ubuntu.com/oracular/gnupg
I reconstructed the following timeline:
Debian bullseye hard freeze[1]: 2021-03-12
According to Upstream[2], GnuPG 2.4 birth: 2021-04-07 (maybe as devel)
Debian bullseye full freeze[1]: 2021-07-17
First package (2.4.0) in experimental[3]: 2022-12-25
Debian bookworm hard freeze[4]: 2023-03-12
Debian bookworm full freeze[4]: 2023-05-24
Ubuntu 24.04 LTS (Noble Numbat) release[5]: 2024-04
RNP LibrePGP support[6]: 2024-07-22
OpenPGP RFC 9580 release[7]: 2024-07-31
For example, OpenPGP certificates produced by earlier versions of 2.4
and imported into Thunderbird advertised non-standardized encryption mechanisms that Thunderbird didn't support, which led to unreadable
mails for those users.
Is this still a problem with GnuPG 2.4.7? Can this be adjusted by
changing default configuration in the Debian package? Does it need
a code patch?
Thunderbird seems to use the RNP[8] crypto library which supports[...]
a cooperative workflow with GnuPG via LibrePGP. Are there patches
to remove this behaviour in Debian?
Thanks for this discussion, all--
On Tue 2025-01-07 15:16:27 +0100, Simon Josefsson wrote:
I believe this would be good, I frequently run into GnuPG bugs in the
2.2.x branch that was fixed years ago in 2.4
Can you identify some of those bugs? It would be good to be clear about
what 2.2 is lacking.
On 2025-01-10 Frank Guthausen <fg.debian@shimps.de> wrote:
Is this still a problem with GnuPG 2.4.7? Can this be adjusted by
changing default configuration in the Debian package? Does it need
a code patch?
Patch. This is about AEAD OCB.
Aside from GnuPG's ongoing architectural challenges, the thing i
personally most want to avoid for Debian would be contributing to the
schism where longstanding users of OpenPGP are suddenly migrated to non-OpenPGP artifacts that other OpenPGP implementations can't or won't support. GnuPG seems to be going their own way there, despite
documented problems with some of their chosen cryptographic constructs
like [v5-v3-signature-aliases] and [encryption-key-separation].
[v5-v3-signature-aliases] https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/130
[encryption-key-separation] https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/101
It seems there is push from the anti-GnuPG people to promote a fork
called FreePG instead of real GnuPG, will you package that?
https://gitlab.com/freepg/gnupg
All the relevant 2.2 patches in the FreePG repository are already in
Debian's unstable branch, and in most cases we have been shipping them
for years to address user needs that upstream GnuPG declines to
acknowledge or support. I've uploaded 2.2.46 today with our patches
renamed to match the names and annotations of this cross-distro effort.
I'm gradually trying to push other pieces of our divergence into the
FreePG patchset so that other distributions that want to keep shipping
GnuPG can arrive at a common and functional baseline. This gives us opportunities to get feedback from other distros as well. In the ideal
case, of course, we'd eliminate all our divergence from upstream, but
that would depend on upstream being interested in working with the use
cases and concerns that our users have.
The FreePG project's visibility is also attracting attention from some
other downstreams of GnuPG that have distinct fixes that they've been carrying that i hadn't been aware of, and we might end up adopting some
of their changes too.
If Andreas is interested, i'm happy to do the same alignment with the
FreePG patchset on the debian packaging for 2.4 (the debian/experimental branch) too, to gather the same sort of cross-distro consensus.
If so I think there would be value in having the real GnuPG as a
separate Debian package, for those who want to use the real version.
Which of the patches in FreePG do you think are harmful for debian
users?
As someone who has contributed years of labor into making sure GnuPG
provides a functional (if not quite as usable or robust as i would
like) interface to OpenPGP users on debian and derived distros, our divergence from GnuPG upstream is a carefully curated set that tries
to address the most significant problems that upstream has declined to accept.
So far, the FreePG patches seem to align pretty closely with that vision
(and where they don't align we can either skip them completely, or
propose improvements in the FreePG project just as we would with any reasonable upstream).
It doesn't seem like normal practice to ask other debian maintainer
teams that are carrying patches requested by users but dismissed by
upstream to ship "the real version" of the upstream codebase. Is there
a reason that GnuPG needs such a process?
I welcome review and critique of the packaging for this tricky package,
which is pretty deeply embedded in Debian (though getting less so, as
apt no longer requires it and we have many other OpenPGP implementations available today). I'd be even more delighted with offers of active co-maintenance beyond the work that Andreas and i have been doing.
Daniel Kahn Gillmor <dkg@debian.org> writes:
I welcome review and critique of the packaging for this tricky package, which is pretty deeply embedded in Debian (though getting less so, as
apt no longer requires it and we have many other OpenPGP implementations available today). I'd be even more delighted with offers of active co-maintenance beyond the work that Andreas and i have been doing.
I've offered help, but my impression has been that it not giving up on
the schism thing has been more important than getting Debian to ship
upstream code to users and let people decide what they want to use.
Sometimes it is better to let other make decisions rather than to make decisions for others.
the way you want. This is even more true considering that the people
who are patching GnuPG seems to be the same people who are working on replacing GnuPG with Seqoia.
On Mon, Jan 13, 2025 at 11:08:11AM +0100, Simon Josefsson wrote:
Daniel Kahn Gillmor <dkg@debian.org> writes:
I welcome review and critique of the packaging for this tricky package,
which is pretty deeply embedded in Debian (though getting less so, as
apt no longer requires it and we have many other OpenPGP implementations >> > available today). I'd be even more delighted with offers of active
co-maintenance beyond the work that Andreas and i have been doing.
I've offered help, but my impression has been that it not giving up on
the schism thing has been more important than getting Debian to ship
upstream code to users and let people decide what they want to use.
Sometimes it is better to let other make decisions rather than to make
decisions for others.
I agree, but in this instance given the reliance we have upon GnuPG throughout the Debian ecosystem I believe it's important we ensure that
the default configuration of what we ship is compatible with OpenPGP.
Power users can feel free to play with OpenPGP v6 / LibrePGP
enhancements, but for the vast majority of folk sticking to RFC
compliant v4 is going to make the most sense.
I actually meant missing features. From my recollection it was features related to support for some subset of combinations of 25519, gpgsm, smartcards and the gpg/ssh agent. Things didn't work in GnuPG 2.2 but
was fixed years ago in 2.4.
Thanks for this discussion, all--
On Tue 2025-01-07 15:16:27 +0100, Simon Josefsson wrote:
I believe this would be good, I frequently run into GnuPG bugs in the
2.2.x branch that was fixed years ago in 2.4
Can you identify some of those bugs? It would be good to be clear about
what 2.2 is lacking.
On Mon 2025-01-13 10:53:30 +0100, Simon Josefsson wrote:
I actually meant missing features. From my recollection it was features
related to support for some subset of combinations of 25519, gpgsm,
smartcards and the gpg/ssh agent. Things didn't work in GnuPG 2.2 but
was fixed years ago in 2.4.
If you could identify the specific missing feature, i'd love to try to
figure out what's going on there (with either 2.2 or 2.4). A bug report would be particularly useful. Thanks!
Jonathan McDowell <noodles@earth.li> writes:[...]
[...]I agree, but in this instance given the reliance we have upon GnuPG throughout the Debian ecosystem I believe it's important we ensure that
the default configuration of what we ship is compatible with OpenPGP.
Power users can feel free to play with OpenPGP v6 / LibrePGP
enhancements, but for the vast majority of folk sticking to RFC
compliant v4 is going to make the most sense.
I understand this concern, but I believe there is a strong bias for
Debian developers to care about our own use-cases a lot which may not be particulary relevant outside the scope of Debian-internal development.
I believe it would be perfectly fine to ship verbatim upstream unpatched GnuPG 2.4 and work out any Debian-specific quirks and requirements we
have and put quirks into tools that are external to GnuPG itself.
Jonathan McDowell <noodles@earth.li> writes:
On Mon, Jan 13, 2025 at 11:08:11AM +0100, Simon Josefsson wrote:
Daniel Kahn Gillmor <dkg@debian.org> writes:
I welcome review and critique of the packaging for this tricky package, >> > which is pretty deeply embedded in Debian (though getting less so, as
apt no longer requires it and we have many other OpenPGP implementations >> > available today). I'd be even more delighted with offers of active
co-maintenance beyond the work that Andreas and i have been doing.
I've offered help, but my impression has been that it not giving up on
the schism thing has been more important than getting Debian to ship
upstream code to users and let people decide what they want to use.
Sometimes it is better to let other make decisions rather than to make
decisions for others.
I agree, but in this instance given the reliance we have upon GnuPG throughout the Debian ecosystem I believe it's important we ensure that
the default configuration of what we ship is compatible with OpenPGP.
Power users can feel free to play with OpenPGP v6 / LibrePGP
enhancements, but for the vast majority of folk sticking to RFC
compliant v4 is going to make the most sense.
I understand this concern, but I believe there is a strong bias for
Debian developers to care about our own use-cases a lot which may not be particulary relevant outside the scope of Debian-internal development.
I believe it would be perfectly fine to ship verbatim upstream unpatched GnuPG 2.4 and work out any Debian-specific quirks and requirements we
have and put quirks into tools that are external to GnuPG itself.
It seems there is push from the anti-GnuPG people to promote a fork called FreePG instead of real GnuPG, will you package that?
https://gitlab.com/freepg/gnupg
Who is behind FreePG?
Or do we want to trust 'Hooty McOwlface' with no earlier publicly recorded community contributions?
This is even more true considering that the people who are patching GnuPG seems to be the same people who are working on replacing GnuPG with Seqoia.
Simon Joseffson <simon@joseffson.org <mailto:simon@joseffson.org>> wrote:
It seems there is push from the anti-GnuPG people to promote a fork
called FreePG instead of real GnuPG, will you package that?
https://gitlab.com/freepg/gnupg
FreePG is not an anti-GnuPG project, if anything it’s trying to keep
GnuPG on Linux alive as long as possible, so as not to force users
into a disruptive sudden migration to other tools. It is also very deliberately not a fork, but rather a set of discrete patches that are already being applied by multiple downstreams, some dating back years.
I don't think it is a good idea to use the powers that comes by being a package maintainer or distribution to force changes of how some piece of software is supposed to work by patching it without changing its name.We have been doing this since Debian exists, so I think that you will
And also please upload verbatim upstream GnuPG separately. This allowsWhy don't YOU do it, if you really care so much?
user choice.
If the justification for those modifications are disagreement with
upstream about how GnuPG should behave with regard to the wire
protocol, it becomes even more clear to me that we are talking about a
fork.
What is GnuPG? Upstreams GnuPG or Debian's GnuPG or Fedora's GnuPG or Hooty's GnuPG? This situation is bad both for Debian and GnuPG, and to
the wider PGP eco-system.
If there is commitment to provide long-term support for FreePG, how
about uploading that as a separate package in Debian?
And also please upload verbatim upstream GnuPG separately. This allows
user choice.
Do you have earlier examples of Debian modifying upstream's desired wire crypto-sensitive protocol in the way like what is being done for GnuPG?Like the Kerberos patch for OpenSSH?
Maybe there are some older OpenSSH or OpenSSL patches like that.
On Jan 14, Simon Josefsson <simon@josefsson.org> wrote:
I don't think it is a good idea to use the powers that comes by being aWe have been doing this since Debian exists, so I think that you will
package maintainer or distribution to force changes of how some piece of
software is supposed to work by patching it without changing its name.
have to express a much more articulate argument than "I don't think it
is a good idea".
And also please upload verbatim upstream GnuPG separately. This allowsWhy don't YOU do it, if you really care so much?
user choice.
As a project we have no moral or technical obligations to provide
choices that we do not personally care about.
On Jan 14, Simon Josefsson <simon@josefsson.org> wrote:
Do you have earlier examples of Debian modifying upstream's desired wireLike the Kerberos patch for OpenSSH?
crypto-sensitive protocol in the way like what is being done for GnuPG?
Maybe there are some older OpenSSH or OpenSSL patches like that.
Do you have earlier examples of Debian modifying upstream's desired wire crypto-sensitive protocol in the way like what is being done for GnuPG?
Maybe there are some older OpenSSH or OpenSSL patches like that.
I am hoping that the 'gnupg2' package could be altered towards that
goal, and that some sort of compromise with the GnuPG Debian maintainers
can be reached that providing a LibrePGP-compliant GnuPG in Debian is acceptable.
Afaik there is no /known/ blocker except for the
libgnupg-interface-perl test error #1088155.
On Tue, 7 Jan 2025 19:01:51 +0100
Andreas Metzler <ametzler@bebt.de> wrote:
Afaik there is no /known/ blocker except for the
libgnupg-interface-perl test error #1088155.
According to bug report[1] there are failed subtests in 2.4.6 but these
are not specified. What causes this failures and what needs to be done
to resolv the bug? Is the situation unchanged with 2.4.7? Is there a
patch missing? Configuration issue? Is this a bug in the test suite
itself?
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1088155
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 153:09:11 |
| Calls: | 10,383 |
| Files: | 14,054 |
| Messages: | 6,417,828 |