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.
Description: PGP signature