Your message dated Sun, 23 Feb 2025 23:15:16 +0100
with message-id <874j0kl34b....@josefsson.org>
and subject line Re: Bug#1093026: ITP: gnupg24 -- GNU Privacy Guard, a LibrePGP
implementation
has caused the Debian Bug report #1093026,
regarding ITP: gnupg24 -- GNU Privacy Guard, a LibrePGP implementation
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1093026: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093026
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: wnpp
Severity: wishlist
Owner: Simon Josefsson <si...@josefsson.org>
X-Debbugs-CC: debian-de...@lists.debian.org
* Package name : gnupg24
Version : 2.4.7
Upstream Author : Werner Koch, et al
* URL : https://www.gnupg.org/
* License : GPL
Programming Lang: C
Description : GNU Privacy Guard, a LibrePGP implementation
The intent with this package is to provide a LibrePGP-compliant variant
of GnuPG in Debian.
Packaging is based on the 'gnupg2' source package from experimental, and
will be maintained here:
https://salsa.debian.org/debian/gnupg-24/
The idea is to minimize the existing packaging into the most minimal set
of binary packages required to support a more upstream-like GnuPG 2.4.x
experience in Debian.
Hopefully only two new binary packages called 'gpg24' and 'gpgv24' will
be needed.
I am hoping that most of the auxilliary packages like scdaemon does not
need to be provided by this source package, but can be shared with the
GnuPG/FreePG variant already packaged in Debian in the 'gnupg2' source
package.
/Simon
signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Daniel Kahn Gillmor <d...@debian.org> writes:
> On Sun 2025-02-09 10:52:47 +0100, Emilio Pozuelo Monfort wrote:
>> I agree with this sentiment, and with my Release Team hat on, I don't
>> think we want to have three implementations in trixie. You should work
>> with the maintainer to try and get it updated if possible, and
>> otherwise maybe it can be uploaded to -backports post trixie release.
>
> fwiw, Simon and i had a good conversation a little while ago about some
> reasonable strategies going forward for GnuPG in debian.
>
> I've spent the time since then looking at trying to make some changes in
> the debian experimental packaging for 2.4, and 2.4.7-4 (in experimental
> now) is the result of the first phase of that work.
>
> (i tried submitting some of those changes upstream, but even the
> beginning parts which i thought would be mostly unobjectionable were
> either rejected or ignored upstream for reasons i can't say i fully
> understand (https://dev.gnupg.org/T7511), so alas it means we'll be
> carrying an even heavier patch load, sigh)
>
> The NEWS file entry for 2.4.7-4 sums up the overall gist of the approach
> i've taken:
>
> ------
> gnupg2 (2.4.7-4) unstable; urgency=medium
>
> The upstream GnuPG project now explicitly and deliberately diverges from
> the OpenPGP standard. Debian's own workflows rely heavily on OpenPGP,
> and we ship several different OpenPGP implementations, so
> interoperability via standardization is a priority for the project.
>
> While Debian still has significant dependencies on GnuPG, the version of
> GnuPG shipped in Debian will default to emitting only OpenPGP-compatible
> artifacts if at all possible. As of 2.4.7-4, the default
> is --compliance=openpgp, and we apply several patches to ensure that
> this mode is respected.
>
> If you observe GnuPG in Debian emitting a non-OpenPGP artifact in a
> scenario where a standard OpenPGP artifact is intended or expected,
> please open a critical bug report in the Debian BTS.
>
> If you want Debian's GnuPG to emit non-standardized artifacts, in line
> with upstream's deliberate divergence, you can explicitly pass
> --compliance=gnupg (or set the corresponding option in
> ~/.gnupg/gpg.conf). If you revert to compliance with upstream defaults,
> do not expect the material you produce to be interoperable with other
> OpenPGP implementations.
>
> -- Daniel Kahn Gillmor <d...@fifthhorseman.net> Fri, 07 Feb 2025 23:35:29
> -0500
> ------
>
> Simon, i don't know whether this approach would be acceptable to you or
> not.
I think my main concerns here are that 1) GnuPG 2.4.x is not uploaded to
sid/trixie and that this lowers security for users to the GnuPG 2.2 era,
and 2) that the Debian GnuPG team is patching GnuPG to deviate from what
upstream desire in a deep way.
I'm not in a position that my acceptance or not matters, and it seems to
me that there are fundamental different priorities in play here (pushing
the pro-OpenPGP-anti-GnuPG agenda), and further that the release team
seems negative to provide GnuPG-as-upstream-desires-it-to-be in Debian,
so that sadly leaves me seeing no way to contibute to Debian anything to
help users who (like myself) would like to be able to use the real GnuPG
2.4 in Debian environments. So I'm closing the gnupg24 ITP bug.
My recommendation for people who want to use GnuPG 2.4 on Debian system
is to build and install it themselves. I've switched to Guix's GnuPG
packages myself, which run fine on Debian-derived systems like Ubuntu or
Trisquel, and gives me a recent GnuPG version 2.4.7. I also suggest
people consider the Debian GnuPG packages as a non-renamed fork with
different objectives than GnuPG upstream and therefor users have to be
careful with the resulting configuration.
/Simon
>
> My preference would be for upstream to maintain a sensible
> --compliance=openpgp mode, and then all that i think Simon and i would
> disagree about would be whether debian changes the default compliance
> mode in what we ship. But apparently upstream doesn't even want to
> accept patches that would create a realistic --compliance=openpgp mode,
> so to the extent that we need OpenPGP interoperability in Debian we are
> gonna need to carry some patches.
>
> I'm also trying to coordinate those patches with other distros that have
> similar concerns (e.g. Fedora and Arch) via the FreePG project so that
> we're not entirely on our own:
>
> https://gitlab.com/freepg/gnupg/-/merge_requests/14
>
> I'll also note that as i've been doing this work, i ended up opening
> https://bugs.debian.org/1095515 (thanks Andreas for pointing me to the
> relevant details and history which i'd either missed or forgotten); i'm
> not sure the right way to resolve this, but it seems likely to break
> some significant tooling in subtle ways if we move 2.4 from experimental
> to unstable.
>
> What do i mean by "subtle ways"? I mean it won't break for everyone,
> only for people with certain configurations, using the tool in a certain
> way; and the breakage is nearly silent breakage, just a single warning
> line on an already noisy stderr, not explicit error return codes or
> status-fd output, while regular output and processing happens on a
> different dataset than expected. These are the hardest kinds of bugs to
> deal with in my experience, especially in a tool like GnuPG that is
> (correctly!) more often used in scripted or wrapped environments than
> executed by the user on the command line.
>
> Anyway, that's the current state of play from my perspective. I hope
> folks who care about GnuPG in debian and are willing to take some risks
> will try the packaging in experimental and give feedback.
>
> --dkg
>
signature.asc
Description: PGP signature
--- End Message ---
