Re: Questioning debian/upstream/signing-key.asc
On 2021-03-26 Christoph Biedl <email@example.com> wrote:
> 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.
> 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?
I think there are two different issues at hand.
Uploading a new upstream version of a package where
debian/upstream/signing-key.asc is expired or does not
match the uploaded upstream signature is a (minor) bug.
Otoh having a debian/upstream/signing-key.asc which expired *since*
the first upload of the upstream version is kind of the natural way of
things. When a new version appears we download it and check the
signature. If it does not verify we will investigate, perhaps the
key expired and was extended or a new key was used. Trying to do this
before we look at (and actually have a new upstream) is error-prone
could be make-work. (No new upstream released before this key experies,
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'