Bug#964971: lintian: please consider new check: expired keys in debian/upstream/signing-key.asc
Hello, On Wed, Mar 24, 2021 at 09:59:59AM +0100, Christoph Biedl wrote: > Felix Lechner wrote... > > > 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. > > That argument seems fairly weird to me: Abandon or deny features because > they are difficult to test. By the way, to test behaviour over time, > faketime(1) serves me good enough. But that's your design decision. Just to make this suggestion more obvious as I got (and needed) this hint: A sensible date to fake (or compare to) would probably be the changelog date. Then the output doesn't vary over time and we also don't get bad positives for old packages. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Bug#964971: lintian: please consider new check: expired keys in debian/upstream/signing-key.asc
Good morning Felix, Felix Lechner wrote on Tue, Mar 23, 2021 at 14:16:26 -0700: > Hi Daniel, > > On Mon, Jul 13, 2020 at 8:27 AM Daniel Shahaf wrote: > > > > a debian/upstream/signing-key.asc file > > which contains an expired snapshot of upstream's signing key > > Did uscan give you any trouble when trying to validate upstream's > release signature? In zsh-syntax-highlighting's packaging I don't use uscan(1). I just git-merge(1) the new upstream tag, and use git-archive(1) to fake a .orig tarball. According to comments in zsh-syntax-highlighting's debian/README.source and debian/source/lintian-overrides, uscan(1) was avoided because upstream produces signed tags but not signed tarballs, and no way was identified to have uscan(1) verify them. Thus, the automation that calls git-archive(1) also handles verification manually. In my specific case, I don't actually need the verification at all because I happen to upstream's release manager and sign the tags myself in that capacity, but the workflow doesn't depend on this. Cheers, Daniel > Kind regards > Felix Lechner >
Bug#964971: lintian: please consider new check: expired keys in debian/upstream/signing-key.asc
Hi Christoph, On Wed, Mar 24, 2021 at 2:00 AM Christoph Biedl wrote: > > But that's your design decision. No, it's an indicator that another QA tool might be a better place for the warning. > Other people's workflow might be different, though. Everyone with a key uses 'uscan', and that is the right place to warn about expired keys. It is not necessary to upload new Debian revisions because a key is expired. > Also, in lintian the change was rather small and therefore easy to > implement. The resulting tag is not useful for a package at rest. Think about it this way: Many old packages may trigger the tag in the archive, but there is no need to fix anything. Dead upstream sources also illustrate that point. > How do the other signing key checks do that? Where's the difference? Keys that are not minimal, for example, take up space. We have keys with over a thousand third-party signatures in the archive. [1] Keys with weak hashes are a security risk. So are known compromised keys. Expired keys, on the other hand, are not a package quality issue. They will get updated in the course of time. [1] https://lintian.debian.org/sources/xandikos/0.2.2-1.html > it would still avoid breaking uscan in the future. Uscan uses the network, but Lintian does not. In a similar vein, Lintian can also not fix broken download URLs—which are arguably a much bigger problem. (For an extended discussion, please see Bug#985633 about recent changes at Github.) Errors that arise when trying to access and validate new sources will be flagged right then and there. Without a new release, there is no need to update the key. From my experience, that is also the attitude of upstream personnel, who may only extend or distribute new keys at release time. > It would alert if the key already has expired As I reasoned here, that is not valuable information for a package at rest. Lintian is a static analysis tool. > the maintainer can update accordingly before breaking the > validation chain. The maintainer cannot download new versions without a validation chain. The issue is always solved before Lintian runs. Lintian is the wrong place to point it out. It is too late in the workflow, and cannot arise naturally unless the maintainer intentionally works with unvalidated sources. Kind regards Felix Lechner
Bug#964971: lintian: please consider new check: expired keys in debian/upstream/signing-key.asc
Felix Lechner wrote... > 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. That argument seems fairly weird to me: Abandon or deny features because they are difficult to test. By the way, to test behaviour over time, faketime(1) serves me good enough. But that's your design decision. > It would be more appropriate to flag expired keys on tracker.d.o. Another place might be DDPO - problem with both is visibility. If such a check was implemented in Lintian, package maintainers get any issues right in their face when building the package (which usually includes running lintian). Tracker or DDPO, I these those only occasionally. Other people's workflow might be different, though. Also, in lintian the change was rather small and therefore easy to implement. > Expired keys also do not affect package quality in the archive. How do the other signing key checks do that? Where's the difference? > 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. Assuming upstream already updated the signing key, it would still avoid breaking uscan in the future. It would alert if the key already has expired, something I reckon about libgpg-error (key expiry December 2019, new upstream release uploads in March and June 2020). It could (after an extension of the check) warn about an upcoming expiration so the maintainer can update accordingly before breaking the validation chain. And yes, that's time-based behaviour. Christoph signature.asc Description: PGP signature
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 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
Bug#964971: lintian: please consider new check: expired keys in debian/upstream/signing-key.asc
Felix Lechner wrote... > Did uscan give you any trouble when trying to validate upstream's > release signature? Try libgpg-error before #985793 gets fixed: uscan: Newest version of libgpg-error on remote site is 1.42, local version is 1.38 uscan: => Newer package available from: => https://gnupg.org/ftp/gcrypt/libgpg-error/libgpg-error-1.42.tar.bz2 gpgv: Signature made Mon 22 Mar 2021 11:50:29 AM CET gpgv:using EDDSA key 6DAA6E64A76D2840571B4902528897B826403ADA gpgv: Can't check signature: No public key uscan die: OpenPGP signature did not verify. at /usr/share/perl5/Devscripts/Uscan/Output.pm line 60. Exit code 2 Christoph signature.asc Description: PGP signature
Bug#964971: lintian: please consider new check: expired keys in debian/upstream/signing-key.asc
Hi Daniel, On Mon, Jul 13, 2020 at 8:27 AM Daniel Shahaf wrote: > > a debian/upstream/signing-key.asc file > which contains an expired snapshot of upstream's signing key Did uscan give you any trouble when trying to validate upstream's release signature? Kind regards Felix Lechner
Bug#964971: lintian: please consider new check: expired keys in debian/upstream/signing-key.asc
Axel Beckert wrote...
> That might be something for lintian-brush once a lintian check is
> there. Cc'ing Jelmer, the author of lintian-brush.
What's the status of that story? I hacked a few lines together that work at
least for the case where I encountered the problem. But it's fairly
fragile since parsing in a textual output is bad. It was way better to
*omit* --list-packets in the gpg invocation since then the output is by
definition machine-readable (and there is an "Expired!" alert on stderr
for free). Also upstream warns the output of --list-packets "may change
with new releases."
Christoph
--- /usr/share/lintian/checks/debian/upstream/signing-key.pm
+++ /usr/share/lintian/checks/debian/upstream/signing-key.pm
@@ -122,15 +122,20 @@
# look for third-party signatures
my @thirdparty;
+my $expired;
for my $packet (@packets) {
my $header = $packet->[0];
+my $body = $packet->[1];
if ($header =~ qr/^:signature packet: algo \d+, keyid (\S*)$/){
my $signatory = $1;
push(@thirdparty, $signatory)
unless $signatory eq $keyid;
}
+if ($body =~ qr/ expires 0/) {
+$expired = 1;
+}
}
# signatures by parties other than self
@@ -141,6 +146,9 @@
$key_name,
"has $extrasignatures extra signature(s) for keyid $keyid")
if $extrasignatures;
+$self->hint('public-upstream-key-expired',
+$key_name,'has expired keys')
+ if $expired;
}
}
Tag: public-upstream-key-expired
Severity: info
Check: debian/upstream/signing-key
See-Also: uscan(1)
Explanation: The source package contains a public upstream signing key that
contains at least one key that has expired.
.
Please obtain the correct key from upstream.
signature.asc
Description: PGP signature
Bug#964971: lintian: please consider new check: expired keys in debian/upstream/signing-key.asc
Hi, Daniel Shahaf wrote: > After extending the key I re-pushed it to keyservers, but did not > regenerate the d/u/signing-key.asc export. (I'd like to automate > that regeneration, since my key appears in multiple packages' > signing-key.asc files, but that's a question for another thread.) That might be something for lintian-brush once a lintian check is there. Cc'ing Jelmer, the author of lintian-brush. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#964971: lintian: please consider new check: expired keys in debian/upstream/signing-key.asc
Package: lintian Version: 2.83.0 Severity: wishlist Tags: upstream Dear Maintainer, I noticed yesterday that the current source package of zsh-syntax-highlighting contains a debian/upstream/signing-key.asc file which contains an expired snapshot of upstream's signing key: the snapshot gives the key's expiration date as 2018-06-28.¹ I then generated and built that package on a then-current sid chroot and observed that no lintian warnings were logged about the expired key. I invoked lintian as «lintian --display-info --display-experimental --pedantic --color=always --no-tag-display-limit /build/*.changes /build/*.dsc /build/*.deb». I was wondering whether it would be a good idea for Lintian to add a check for expired keys in debian/upstream/signing-key.asc. Despite the name being in singular, signing-key.asc may contain multiple keys, just like upstream tar.gz.asc files may contain multiple people's signatures. I am not sure what the semantics of the check should be when that file contains multiple keys, only some of which are expired. When upstream's release manager (RM)'s identity changes, it can be useful to keep carrying the outgoing RM's public key, in order to make it easier to verify past and potential future upstream releases signed with that key. However, someone who had stepped down from being RM might let their key expire and not renew it until and unless they resume being the RM. An alternative point of view is that signing-key.asc should contain only keys that are currently in use, and older keys should be removed (they'll still be available in archived sourced packages). Under this point of view, there might be room for an additional check that the keys in signing-key.asc are indeed those keys used to sign the upstream tarball. Cheers, Daniel ¹ In this particular case, upstream's key is my key, and that key has been regularly extended (to 2020-07-01 and to 2021-12-31). After extending the key I re-pushed it to keyservers, but did not regenerate the d/u/signing-key.asc export. (I'd like to automate that regeneration, since my key appears in multiple packages' signing-key.asc files, but that's a question for another thread.)
