[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#964971: lintian: please consider new check: expired keys in debian/upstream/signing-key.asc



Hi Christoph,

On Tue, Mar 23, 2021 at 2:23 PM Christoph Biedl
<debian.axhn@manchmal.in-ulm.de> wrote:
>
>     gpgv: Can't check signature: No public key

That makes sense. I had a similar issue with wolfssl. Version 4.6.0-3
in unstable still contains the expired public key, but the validation
worked previously. As this open issue [1] suggests, it was probably
because the signature was made before the key expired. For version
4.7.0, it fails:

    uscan die: OpenPGP signature did not verify. at
/usr/share/perl5/Devscripts/Uscan/Output.pm line 60.

By the way, the suggestion behind this bug may not be implemented
anytime soon. It would cause Lintian's output to change over time
(same Lintian version on same package). Such tags are hard to test in
Lintian's test suite. I just got rid of the last known tag like it:

    https://salsa.debian.org/lintian/lintian/-/commit/53ead395a217a8a7969f7f96e3882d2da402c96d

It would be more appropriate to flag expired keys on tracker.d.o.  The
need to update or replace a public key can, generally, only be
detected when trying to validate the most recent release signature. In
Debian's current setup that happens in UDD (via uscan). You can find a
quick note about here:

    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985633#40

Expired keys also do not affect package quality in the archive. They
still validate old release signatures. I believe a maintainer would
have to sidestep uscan intentionally in order to upload a source
package with an upstream public key that turns out to be useless.
Since uscan happens earlier in the workflow, a Lintian tag is not the
right place to detect such key failures.

Kind regards
Felix Lechner

[1] https://dev.gnupg.org/T1537


Reply to: