Bug#982562: general: Storing upstream signatures next to upstream tarballs is problematic
Hi!
On Thu, 2021-02-11 at 21:59:42 +0100, Raphaël Hertzog wrote:
> Package: general
> Severity: normal
> User: devel@kali.org
> Usertags: origin-kali
> X-Debbugs-Cc: hertzog@debian.org, debian-dpkg@lists.debian.org
> Control: affects -1 ftp.debian.org dpkg-dev
> After having been bitten (in Kali) by failures to import Debian packages
> because a PGP signature file has been modified [1], this lead me to think
> about this problem space and I concluded that the way we are storing
> such signatures is not appropriate.
>
> Those files are not really meant to be immutable:
> - signing keys can expire and be revoked, upstream might want to update
> signatures of already released tarballs
These files have similar properties and problems as our own .dsc, so
I don't see a huge difference here.
> - the set of "upstream release managers" might evolve over time and the
> official signature to use might change...
If this changes I'd expect in most cases the signing-key.asc to get
out of date too, anyway.
> If we assume that the archive is meant to store immutable content
> under a given filename (and to me that requirement seems to be a good
> idea), then we should question ourselves whether we really want to store
> those signatures in a filename that's associated to the upstream version.
> They should either be tied to the Debian revision (so that they can change
> over time without any new upstream release) or be incorporated in the
> Debian tarball.
The upstream signatures are important to determine the provenance of
the source at the time of packaging, just like the signatures on .dsc,
both lose relevance once they hit an archive.
> After all the key to verify those signatures is already stored in the
> Debian tarball (when you use the uscan feature to verify those
> signatures), so why not store the signature there as well?
This looks messy, taking into account multi orig support for example.
> I originally filed this in https://bugs.debian.org/949962 against
> ftp.debian.org but the bug got closed because it's not really the
> responsibility of ftpmasters to change this. So I'm starting a wider
> discussion to gather feedback of all interested parties (at least
> Guillem as dpkg maintainer). I won't drive this much further but
> I wanted to have it properly recorded and considered.
This seems mostly a tooling problem TBH.
There's the accidental omissions part, which I also got bitten by at
the beginning, because the error mode was silent. This has since then
been incrementally improved, and now we have lintian warnings and
dpkg-source also warns (when upstream sig is missing but there's
upstream signing keys, and on the reverse too). I attempted to make
the former an error, but stuff was breaking so that had to be reverted
(see #963821). Ideally that would eventually be turned back into an
error, with an option to make it a warning.
Then there's the problem with changing contents for already seen
files, which seems like a dak bug. It does not allow to change a
tarball once it has been seen, so I don't see why it should allow a
changed .asc either?
Thanks,
Guillem
Reply to: