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