Hi Christoph, On Tue, Mar 23, 2021 at 2:23 PM Christoph Biedl <debian.a...@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