.spec file Source0 magic for github release source tarballs?
luto at mit.edu
Mon Jan 27 17:25:42 UTC 2014
On Fri, Jan 24, 2014 at 4:57 PM, Adam Williamson <awilliam at redhat.com> 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...
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.
More information about the devel