Re: 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  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

Re: Don't ship gnupg1 with bullseye

[Paul Gevers]

Hi,

On 02-02-2021 09:54, Dominic Hargreaves wrote:
> The impression I got from the
> release team and Chris Hofstaedtler that request-tracker4 was the only
> thing blocking removal.

The reason I (with my Release Team member hat on) was trying to figure
out what needed to happen to enable removal was an RC bug that has been
fixed since (thanks axhn).

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Re: Don't ship gnupg1 with bullseye

[Russ Allbery]

Dominic Hargreaves  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.

-- 
Russ Allbery (r...@debian.org)  

Re: Don't ship gnupg1 with bullseye

[Dominic Hargreaves]

On Tue, Feb 02, 2021 at 10:26:55AM +0100, Julien Cristau wrote:
> On Tue, Feb 02, 2021 at 09:45:42AM +0100, Christoph Biedl wrote:
> > IMnsHO it's a bad idea to remove gnupg1 any time soon. While it
> > certainly should not be used for encryption, it's still needed when
> > dealing with older keys. Quoting the package description: "It is
> > provided mainly for people with the need to use archaic cryptographic
> > objects like PGPv3 keys to access archived messages."
> > 
> > So unless it's really broken or likewise RC, it should be kept.
> > 
> Agreed.  It's great that no package uses it anymore, but that doesn't
> mean some users won't need it to deal with legacy bits.

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?)

[1] Thanks Andrew for already doing the work for that!

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

[Werner Koch]

On Tue,  2 Feb 2021 09:45, Christoph Biedl said:

> IMnsHO it's a bad idea to remove gnupg1 any time soon. While it
> certainly should not be used for encryption, it's still needed when
> dealing with older keys. Quoting the package description: "It is

And first of all with data encrypted to old keys.

What can be done is to remove the keyserver support (all these helper
binaries should be enough).  This will remove some dependencies.

We could also remove card support but there is a slight chance that
someone is still using a card with data enrypted w/o MDC.  So better
don't touch the card stuff yet.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature

Re: Don't ship gnupg1 with bullseye

[Julien Cristau]

On Tue, Feb 02, 2021 at 09:45:42AM +0100, Christoph Biedl wrote:
> Dominic Hargreaves wrote...
> 
> > Do the gnupg1 maintainers agree that it should be removed from bullseye?
> 
> IMnsHO it's a bad idea to remove gnupg1 any time soon. While it
> certainly should not be used for encryption, it's still needed when
> dealing with older keys. Quoting the package description: "It is
> provided mainly for people with the need to use archaic cryptographic
> objects like PGPv3 keys to access archived messages."
> 
> So unless it's really broken or likewise RC, it should be kept.
> 
Agreed.  It's great that no package uses it anymore, but that doesn't
mean some users won't need it to deal with legacy bits.

Cheers,
Julien

Re: Don't ship gnupg1 with bullseye

[Andrew Ruthven]

Hey,

On Tue, 2021-02-02 at 08:33 +, Dominic Hargreaves wrote:

> Checking reverse dependencies...
> # Broken Depends:
> libgnupg-perl: libgnupg-perl

libgnupg-perl only supports GnuPG v1.4 and given it hasn't had a
release since 2012 I doubt it will gain support for v2.2.

> # Broken Build-Depends:
> libgnupg-interface-perl: gnupg1
> 
> The dependencies in libgnupg-interface-perl and libpgp-sign-perl look
> straightforward to remove.

The build dependency in libgnupg-interface-perl is easy enough to
remove. I've pushed a branch to Salsa called "drop-gnupg1" which does
this along with dropping the tests I added for GnuPG v1 compatibility.

Cheers,
Andrew

-- 
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz |
Catalyst Cloud:   | This space intentionally left blank
 https://catalystcloud.nz |

Re: Don't ship gnupg1 with bullseye

[Dominic Hargreaves]

On Tue, Feb 02, 2021 at 09:45:42AM +0100, Christoph Biedl wrote:
> Dominic Hargreaves wrote...
> 
> > Do the gnupg1 maintainers agree that it should be removed from bullseye?
> 
> IMnsHO it's a bad idea to remove gnupg1 any time soon. While it
> certainly should not be used for encryption, it's still needed when
> dealing with older keys. Quoting the package description: "It is
> provided mainly for people with the need to use archaic cryptographic
> objects like PGPv3 keys to access archived messages."
> 
> So unless it's really broken or likewise RC, it should be kept.

Ah, I wasn't aware of that use case. The impression I got from the
release team and Chris Hofstaedtler that request-tracker4 was the only
thing blocking removal.

Dominic

Re: Don't ship gnupg1 with bullseye

[Christoph Biedl]

Dominic Hargreaves wrote...

> Do the gnupg1 maintainers agree that it should be removed from bullseye?

IMnsHO it's a bad idea to remove gnupg1 any time soon. While it
certainly should not be used for encryption, it's still needed when
dealing with older keys. Quoting the package description: "It is
provided mainly for people with the need to use archaic cryptographic
objects like PGPv3 keys to access archived messages."

So unless it's really broken or likewise RC, it should be kept.

Christoph


signature.asc
Description: PGP signature

Don't ship gnupg1 with bullseye

[Dominic Hargreaves]

Hi all,

With the upload of request-tracker4 4.4.4+dfsg-1, there are (if
 is
correct) no more runtime dependencies on gnupg1 in unstable.

$ ssh mirror.ftp-master.debian.org "dak rm -Rn gnupg1"
...
Checking reverse dependencies...
# Broken Depends:
libgnupg-perl: libgnupg-perl

# Broken Build-Depends:
libgnupg-interface-perl: gnupg1
libgnupg-perl: gnupg1
libpgp-sign-perl: gnupg1

$ ssh mirror.ftp-master.debian.org "dak rm -Rn libgnupg-perl"
...
No dependency problem found.

The dependencies in libgnupg-interface-perl and libpgp-sign-perl look
straightforward to remove.

Because we're so close to the freeze, I figured I should loop the
affected maintainers and the release team in directly too.

Do the gnupg1 maintainers agree that it should be removed from bullseye?

Cheers
Dominic