Hi Daniel, On Fri, Mar 1, 2019 at 4:12 AM Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote: > > > I think what you're describing takes aim a different problem, so i don't > think it addresses the underlying concern here.
I believe it solves your problem, just not the way you expect. As you point out, the current approach of validating different upstream signature formats is the point of this bug. You list two, but as you note there could be more: > At issue in #920763 is our attempt to capture verified *upstream* > cryptographic signatures. There are (at least) two common practices for > such signatures by upstreams across the free software ecosystem: > > a) detached signatures over tarballs > b) signed git tags 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? My shipping manifest offers an "origin statement" to include git or tarball signatures (even multiple) that tie the original source (in any format) to the list of file hashes. Signed by a Debian maintainer, the manifest provides a trust path. 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). > aiui, your tool is > designed to something operated by the debian developer/maintainer. > That cannot be an obstacle. You just suggested it earlier in this thread: I guess if we wanted some version of lintian to be able to check on the > git tag, we need to have some sort of export (git shallow > something-or-other?) that could be included in debian/ to recreate a git > repo that would be sufficient to verify the contents of the files and > confirm the git signature. > Yours were the very words that made me believe I could help. :) A signed manifest is less complex, more universal, and would likely take up less space. As an aside, maintainer involvement is always required when repacking for DFSG-compliance. A manifest with an origin statement would handle that case with ease. > Today, we have pretty decent tooling to handle (a). we even distribute> upstream tarball signatures directly when we have them: > (e.g. https://mirrors.edge.kernel.org/debian/pool/main/k/knot/knot_2.6.8.orig.tar.xz > can be verified against the upstream signer's key by fetching > https://mirrors.edge.kernel.org/debian/pool/main/k/knot/knot_2.6.8.orig.tar.xz.asc ) > > So for (a), we're effectively assembling an archive of all of the > upstream signatures that we know about, which could be used later for > verifying provenance of the source code used. > > What we don't have is tooling to handle or aggregate such a verifiable > archive for those upstream signatures that fall under (b). Do you think > the tool you're describing would help with that? I believe my tool covers a) and b) as well as any other past, current, or future authentication method for upstream sources. As a side note, the signed manifest could even be the sole item uploaded for a new version if it also includes a list of URLs where the sources may be found. Right now, I call it the Light Upload Format. Kind regards, Felix
