[dropping pkg-request-tracker-maintainers] On Tue, Feb 02, 2021 at 09:10:57AM -0800, Russ Allbery wrote: > Dominic Hargreaves <d...@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
