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