Bug#964971: lintian: please consider new check: expired keys in debian/upstream/signing-key.asc
Hi Christoph,
On Wed, Mar 24, 2021 at 2:00 AM Christoph Biedl
<debian.axhn@manchmal.in-ulm.de> wrote:
>
> But that's your design decision.
No, it's an indicator that another QA tool might be a better place for
the warning.
> Other people's workflow might be different, though.
Everyone with a key uses 'uscan', and that is the right place to warn
about expired keys. It is not necessary to upload new Debian revisions
because a key is expired.
> Also, in lintian the change was rather small and therefore easy to
> implement.
The resulting tag is not useful for a package at rest. Think about it
this way: Many old packages may trigger the tag in the archive, but
there is no need to fix anything. Dead upstream sources also
illustrate that point.
> How do the other signing key checks do that? Where's the difference?
Keys that are not minimal, for example, take up space. We have keys
with over a thousand third-party signatures in the archive. [1] Keys
with weak hashes are a security risk. So are known compromised keys.
Expired keys, on the other hand, are not a package quality issue. They
will get updated in the course of time.
[1] https://lintian.debian.org/sources/xandikos/0.2.2-1.html
> it would still avoid breaking uscan in the future.
Uscan uses the network, but Lintian does not. In a similar vein,
Lintian can also not fix broken download URLs—which are arguably a
much bigger problem. (For an extended discussion, please see
Bug#985633 about recent changes at Github.) Errors that arise when
trying to access and validate new sources will be flagged right then
and there.
Without a new release, there is no need to update the key. From my
experience, that is also the attitude of upstream personnel, who may
only extend or distribute new keys at release time.
> It would alert if the key already has expired
As I reasoned here, that is not valuable information for a package at
rest. Lintian is a static analysis tool.
> the maintainer can update accordingly before breaking the
> validation chain.
The maintainer cannot download new versions without a validation
chain. The issue is always solved before Lintian runs. Lintian is the
wrong place to point it out. It is too late in the workflow, and
cannot arise naturally unless the maintainer intentionally works with
unvalidated sources.
Kind regards
Felix Lechner
Reply to: