[pkg-gnupg-maint] Don't ship gnupg1 with bullseye

[Dominic Hargreaves]

[dropping pkg-request-tracker-maintainers]

On Tue, Feb 02, 2021 at 09:10:57AM -0800, Russ Allbery wrote:
> Dominic Hargreaves <dom at earth.li> writes:
> 
> > If it is to stay in Debian indefinitely, I'd suggest we still remove
> > libgnupg-perl and drop support from libgnupg-interface-perl[1] and
> > libpgp-sign-perl. I'm more comfortable with it being there as a
> > standalone binary to be invoked by users to read old data than I am
> > having a programmatic interface being exposed. It sounds like we need
> > some more strong warnings about which part of the package should and
> > shouldn't be used, too (or is that already built into the binary?)
> 
> Usenet still widely uses old keys and old hashes for hierarchy control
> messages (including some of mine, due to lack of time).  I believe GnuPGv2
> flatly refuses to import those old keys, and therefore cannot issue the
> expected control messages or verify the signatures.  We probably do all
> need a collective kick in the pants to move a bit faster on the
> transition, but gnupg1 is still in active use for that reason.  (We are
> slowly migrating; fr.* moved over, and I will do the Big Eight as soon as
> I can carve out enough time.  No one is really trying that hard to forge
> control messages, so it's been a low priority for a bunch of us.)
> 
> libpgp-sign-perl exists primarily to support this use case (it's used by
> News::Article and at least my control message machinery, and I was
> planning on making it a dependency of inn2 at some point in the future),
> and the Build-Depends is to ensure that it continues working with GnuPGv1,
> so I'd prefer not to drop that until GnuPGv1 is no longer in the archive.

Okay, that all makes sense. Thanks everyone for the feedback.
I think the main conclusions are:

* there's definitely a use case for gnupg1 to remain in Debian
* the risks of only using it for its intended uses are fairly low
* there's a use case for libpgpg-sign-perl continuing to exist
* dropping libgnupg-perl - noone has expressed a preference either
  way on this.
* dropping the gpg1 patches in libgnupg-interface-perl - unless they
  get accepted by upstream, I think we should drop them 
* there's a case for stripping down the functionality of gnupg1 so
  that it can only do what it's needed for (see Werner's email).
  I filed #982258 about that
* its description already contains suitable advice about when to
  use it

Dominic