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
signature.asc
Description: PGP signature
