Leo Famulari transcribed 2.3K bytes:
> On Sun, Oct 01, 2017 at 09:20:42PM +0200, Jan Nieuwenhuizen wrote:
> > Jan Nieuwenhuizen writes:
> > 
> > The changing of the libgit-0.26.0 checksum was already reported about 3
> > weeks ago (github seems to only show relative dates)
> > 
> >     https://github.com/libgit2/libgit2/issues/4343
> > 
> > and the bug is still open.  It seems to be a github thing.  As I
> > understand it, currently our options are to update the hash and pray it
> > won't happen again or host libgit2 tarballs ourselves.
> 
> I contacted GitHub about this issue a few weeks ago and they said that:
> 
> 1) They do not guarantee bit-reproducibility of the snapshots they
> generate automatically for each release tag, and they wish that people
> would not rely on them as we do. However, since people *are* relying on
> them, they are discussing this issue internally.
> 2) This is the relevant code change:
> https://git.kernel.org/pub/scm/git/git.git/commit/?id=22f0dcd9634a818a0c83f23ea1a48f2d620c0546
> 
> In the meantime, we can add this to the list of reasons that
> reproducibility is difficult in the long term.
> 
> I don't have any solutions in mind besides keeping substitutes available
> for as long as possible and, for users, using substitutes. We might also
> petition upstream projects to offer a "real" release tarball.

Given that we depend on this for our core functionality,
can't we just keep this on our ftp directory at gnu.org
as a fall-back source in a list?

-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://krosos.org/dist/keys/
https://www.infotropique.org https://krosos.org