Hi Christoph, On Wed, Mar 24, 2021 at 2:00 AM Christoph Biedl <debian.a...@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