On Fri, Jan 24, 2014 at 4:57 PM, Adam Williamson <awilliam@xxxxxxxxxx> wrote: > On Fri, 2014-01-24 at 08:13 -0500, Stephen Gallagher wrote: > >> >> Interesting... However, if you're working with an actual release >> >> tag, I would think Peter's method would be much better. >> > >> > It is a good idea to use a specific commit as your source, not a >> > tag, because the tag can be silently edited, and then you lose >> > source reproducibility. >> > >> > Yes, this is a problem with tarballs too - upstream can always >> > ninja the tarball - but look at it this way: github affords us the >> > ability to avoid that problem, and so we should take it. >> > >> >> Actually, it's not a problem with tarballs. That's *precisely* why we >> store the tarball hashes. This way, we at least know whether they >> still match. > > It's still better to avoid the problem than to know it exists...I don't > think we disagree, I'm just explaining why (I think) it's a good idea to > use a commit ID for a github project even if a tarball is available. > I'm currently working on a way to prove that a tarball matches a git commit id. It's maybe 1/4 done. The idea is that you could do $ xzcat tarball.tar.xz |git untar --commit=1234abc38387272... --prefix=project-1.23 And you'd get an error if the tarball has been tampered with. (Or if the packager messed up.) The main gotcha I can think of so far is that a lot of projects have release scripts that generate autotools files and such. Those wouldn't be compatible with this scheme (or those files could be stripped back out at untar time and regenerated by a specfile, perhaps). If/when this is done and makes it into upstream git, it would be nice to integrate this into rpm / fedpkg / wherever it goes. I know nothing about rpm internals, though. FWIW, heavyweight git tags can't be rewritten. --Andy -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
