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.)
Reply to: