Re: Questioning debian/upstream/signing-key.asc
Hi!
[ Ccing Daniel, as he proposed the shipping of upstream signatures, so
leaving full context. ]
On Fri, 2021-03-26 at 10:13:25 +0100, Christoph Biedl 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.
>
> 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.
I don't think that there was ever any expectation that such signing
certificates would be usable for any future releases though? As these
do not take into account new release maintainers, and changed, revoked
or expired certificates.
> 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.
That's IMO a tooling problem. For example dpkg-source didn't use to
verify these at build time in the past so that's an obvious place this
would be let through unnoticed. Even now it just only warns, which can
be easy to miss. Also I guess people might not always use uscan to
fetch the tarballs.
> So, how to go from here?
Daniel and I happened to discuss issues related to this several days
ago, and we summarized this in
<https://wiki.debian.org/Teams/Dpkg/Spec/UpstreamSigs>.
> The obvious thing to do now was a mass bug filing, and I might
> do that.
I'm not sure that's helpful though? I think instead making our tooling
more strict would be. Stuff like making sure uscan, dpkg-source,
lintian, dupload/dput/dput-ng or even dak error out on these, would
avoid the problem at creation or upload time.
Filing bugs about this seems it would be similar to filing bugs about
signing problems with .dsc IMO.
> 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.
I do think the upstream signatures make sense, as they provide a
provenance chain from Debian, which is helpful f.ex. in case upstream
disappears or the tarballs upstream get modified, or simply to quickly
check whether it was created by an upstream developer.
But this might require more work, as has been mentioned in the thread,
this needs checking what is the state of the signing certificates at
the current time and at the signing time, and the relation of the
owner of that certificate at those times.
In any case the security properties of the upstream tarball signatures
and .dsc/.changes/.buildinfo apply mainly in the path from the upstream
to Debian maintainer up to the Debian archive, where this transitions
to the signatures made by the archive which do support resigning and
automatic key rotation for example.
> 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.
Thanks,
Guillem
Reply to: