Agreed. But the difference is that using full commits a history rewrite will always be detected. Using a tag is making it possible for upstream to bind the same tag to a different commit. And since it's possible, it will happen.
It's a shame there is no way to block forced updates on github. It's a little bit to easy to make a history rewrite there. On Fri, Jan 24, 2014 at 2:13 PM, Stephen Gallagher <sgall...@redhat.com>wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 01/23/2014 05:49 PM, Adam Williamson wrote: > > On Tue, 2014-01-21 at 11:09 -0600, Richard Shaw wrote: > >> On Tue, Jan 21, 2014 at 11:06 AM, Miroslav Suchý > >> <msu...@redhat.com> wrote: On 01/21/2014 06:01 PM, Kaleb KEITHLEY > >> wrote: > >>> > >>> Take, for example, > >> https://github.com/nfs-ganesha/nfs-ganesha/releases, where > >> there's a button for "Source code > >>> (tar.gz)" pointing at > >> https://github.com/nfs-ganesha/nfs-ganesha/archive/V2.0.0.tar.gz > >>> > >>> Note V2.0.0.tar.gz versus nfs-ganesha-2.0.0.tar.gz. > >>> > >>> If I click on that link the downloaded file is named > >> nfs-ganesha-2.0.0.tar.gz by virtue of the Content-Disposition > >> http > >>> header. > >>> > >>> Likewise if I use `curl -L ...` the downloaded file is named > >> nfs-ganesha-2.0.0.tar.gz. > >>> > >>> But for my nfs-ganesha.spec file, if I use the github link > >> shown above, I have to load a file V2.0.0.tar.gz into the > >>> look-aside cache. Anything else and rpm and rpmlint whine. > >>> > >>> Is there a best practice here that I'm missing? > >> > >> > >> https://fedoraproject.org/wiki/Packaging:SourceURL#Github > >> > >> > >> > >> > >> 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. > > 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. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlLiZvsACgkQeiVVYja6o6Pe0wCeNUI3x2sa0br+2qMs2MLmL2yX > GvsAni3A4//1e5s+hXhbUlh75gtpqazp > =fSzG > -----END PGP SIGNATURE----- > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
