On Tue 2019-03-05 10:57:03 -0800, Felix Lechner wrote:
> With source format 3.0 (git) that logic even found a way into the packaging
> system. Let's flip it around for a moment: Why not validate upstream
> signatures when the package is built?
sorry, i think i'm still not following. I *do* validate uptsream
signatures when i build the package. I *also* want other people to be
able to validate those upstream signatures when *they* are inspecting
the source, not just to validate an assertion from me as the debian
maintainer.
It's hard enough to be able to validate direct signatures, and from
years of working in this space, i'm pretty confident in saying that even
the most sophisticated users don't really understand what a "trust path"
is, or how to map it back to a meaningful understanding of the
provenance of a system. That's why i'm thinking here explicitly about
exporting a verifiable upstream signature.
fwiw, the debian developer themselves already distributes a signature
with each new upstream release, which covers the upstream tarball. For
example:
https://tracker.debian.org/news/1028687/accepted-knot-276-1-source-into-unstable/
contains a cryptographic signature from me, over a simple text document
that describes the cryptographic digest of the orig.tar.gz. So we have
an assertion from the debian developer of what they think the upstream
tarball is. So I think i don't understand what additional benefits we'd
get from the mechanism you are describing. Sorry for the confusion!
> To pick up on Chris's comment, the validation happens when our tools can be
> reasonably expected to have network access (or the maintainer has a git
> repo nearby).
I think Chris's comment points to the tooling wanting to guarantee that
things work *without* network access -- just with access to the debian
archive, which i think is a laudable goal. The network can change or
break over time, and we really do want a more reliable archive.
> As an aside, maintainer involvement is always required when repacking for
> DFSG-compliance.
I agree that repacked upstream tarballs *cannot* ship with the most
commonly-distributed forms of verifiable upstream signatures. I think
that's a different problem, though, and probably needs to be solved in a
different way.
--dkg
Attachment:
signature.asc
Description: PGP signature