Hi, I was just talking about similar things on [email protected] and Bug#811565.
Also git tag and git HEAD packaging support is currently in progress. On Fri, Aug 11, 2017 at 02:15:28PM -0400, Daniel Kahn Gillmor wrote: > Package: devscripts > Priority: wishlist > Control: affects -1 + dpkg git-buildpackage pristine-tar > X-Debbugs-Cc: [email protected], [email protected], > [email protected] > > Hi devscripts, dpkg, git-buildpackage, pristine-tar folks-- > > It's awesome to see the progress made on tracking upstream cryptographic > signatures via uscan and dpkg in debian. This provides a dataset for > cryptographic provenance that can be useful for auditing. > > We're handling detached OpenPGP signatures for tarballs at the moment, > but not all upstreams provide this particular form of cryptographic > assurance. > > Some upstreams do provide cryptographic signatures, but only in git > tags. > > I'm not sure exactly how to do this, but what i'd like to see is a way > for us to record and make use of signed git tags in the same way. > > I'm opening this bug report in the hopes of starting discussion about > how to best do it. > > The text below assumes the following: > > * upstream maintains their sources in a git repository. > > * upstream either doesn't produce tarballs at all, or they produce > tarballs from their git repository using something like "git > archive". For the sake of the argument here, let's assume that they > don't produce tarballs at all. > > * upstream does indicate releases in the form of OpenPGP-signed git > tags. > > * The releases offered by upstream correspond to the "upstream > versions" that are uploaded into debian. > > > > Here's an extremely rough and inefficient approach (which i haven't > implemented, as this is in brainstorming phase). I've probably even got > some of the terminology wrong, or the dataflows backward: > > * we document how we generate a debian "upstream tarball" from a git > tag. for example, we put this in debian/upstream/vcs-gen-tarball: > > git archive --format=tar --prefix=${projname}-${version} ${tagname} | > gzip -9n This is already a part of uscan. It needs a bit more refinement. > * make a shallow clone of the git archive at the tag, including the > tag. (i've confirmed that a signed git tag in a shallow repo does > validate correctly). > > git clone --bare --depth 1 -b ${tagname} \ > file://path/to/upstream/${projname}.git ${projname}-${version}.git The quesion is, we need to make local full clone if git is served dumb http server. (Github is smart :-) Shallow clone or git archive does not work if git server is dumb. > * create an archive of the shallow clone, combined with the command to > generate the tarball (we can call this a "gtsig") > > rm -rf ${projname}-${version}.git/hooks > cp debian/upstream/vcs-gen-tarball ./${projname}-${version}.git > tar cz ./${projname}-${version}.git > ./${projname}-${version}.gtsig > > * write a simple tool to verify an orig.tar.gz against a signing key > and a gtsig, by extracting the "shallow clone" of the git repository, > verifying git tag -v, using git-archive, and then comparing the > results. Is this simple? Please show me working example as shell log. > Some of the outstanding concerns: > > * what if there is non-DFSG-free data in the upstream git repo? We > want to make sure we avoid shipping it to our mirrors. that's why i > was leaning toward the "shallow clone", but if there are other > techniques, i'd be curious to hear them. gtsig is from upstream on git repo. So check it there, I think. (Not on tar.) If we do non-DFSG-free tarball generation, maintainer need to sign the tarball. > * the .gtsig will be quite large -- roughly the same size as the I am not quite sure about what you mean here. > orig.tar.gz. Is it possible to make it smaller by just storing the > "delta" needed to recreate the shallow clone from the orig.tar.gz? > Or is it possible (though dirty) to ship the .gtsig itself as the > orig.tar.gz? that smells like trouble, because you couldn't > reconstruct the sources without having git available. > > * the .gtsig itself will show "verified" but it could contain some data > that isn't actually covered by the tag. Upon verification, how do we > make sure it's clean? (i note that OpenPGP signature files also have > covert channels where they can carry unsigned material, so this might > not be introducing a new bug in general). > > * is "git archive" guaranteed to produce deterministic output? > > What do folks think? I'm sure i'm not the first person to think about > this, but i don't know whether there is any existing work done on it > either. Pointers, thoughts, discussion welcome. > > --dkg Anyway, let me get the direct support of git archive first. If it works, we worry about signature. If you know particular archive in mind, let us know. Osamu _______________________________________________ devscripts-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/devscripts-devel
