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.
And it's still possible to 'ninja' a github repository
with a history
rewrite (for example if the upstream discovers that they have content
that was impermissible to distribute, they might retroactively delete
if from the history). This would change all git hashes that occur
after this time.
Sure, possible, but probably less common than people doing 'silent'
releases...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net