Hello,
a few days ago, I ran uscan on a package where I knew there was a new
upstream version - just to encounter an validation error since the
keys in debian/upstream/signing-key.asc had expired.
After that, things escalated a little, and eventually I wrote a script
that downloads d/u/s-k for each source package and examines the
expiration status. And I ended up with:
main contrib
Total number of 32761 161
source packages
Source packages that 2157 8
ship d/u/s-k
Of those:
Failed to parse the file 3 0
Some keys have expired 306 1
All keys have expired 469 2
Another about 40 distinct keys will expire within the next three months.
So for more than 20 percent of the packages with d/u/s-k, it's
impossible to verify a new upstream tarball without extra work. Ouch.
Of course I understand there are various reasons why this happens, and
several are not the maintainer's fault. But at least in some cases it's
obvious the maintainers didn't care: When there has been an upload with
a new upstream version released after the expiration. This has
happened, hopefully they've verified the tarball by other means.
So, how to go from here?
The obvious thing to do now was a mass bug filing, and I might
do that.
However, I uncertain whether is really worth the efforts to maintain
d/u/s-k, or more precisely, ping maintainers to do so. Personally, I
really like it when uscan also validates signatures. But it seems that
enthusiasm isn't quite shared among all contributors.
Christoph
PS: Those who want to argue lintian should for check for such expired
key, I couldn't agree more. Please read the discussion in #985793 first.
Attachment:
signature.asc
Description: PGP signature