Re: What to do about github (dynamic) downloads

["J. Lewis Muir" <jlmuir%imca-cat.org@localhost>]

On 08/10, Filip Hajny wrote:
> > 10. 8. 2017 v 13:40, Greg Troxel <gdt%lexort.com@localhost>:
> > I wonder if we are having problems with things that are actually
> > "releases".  One of the problems of the modern condition is people
> > thinking that software doesn't need releases, and this could all be a
> > symptom of that.
> 
> More on that note, in the above example of protobuf: The links
> with the ‘package’ icon (and ‘/release/‘ in the URL) point
> to binary releases files, which in my understanding need to be
> provided by the project staff. The few with the ‘zip’ icon (and
> ‘/archive/‘ in the URL) are auto-generated by Github every time
> you git-tag a repo. The latter case is much more common, and a
> majority of Github projects only provide these (possibly in connection
> to the standpoint suggested by Greg, that software doesn’t need
> releases).

Good points.  Yes, those ones with the "zip" icon (and "/archive/" in
the URL) are auto-generated by GitHub; I initially didn't notice those.
Still, I think those should always result in an archive file with the
same hash, but somehow they didn't in John's case.

Since the contents were identical, then maybe a timestamp embedded in
the archive changed?

It could be due to a change on GitHub's part, but could it also be a
change on the part of upstream?  For example, if upstream deleted the
already pushed v0.13.1 tag, pushed that change, and then created a new
tag with the same name and pushed that change, that could produce the
observed situation, no?  But I can't imagine them doing that and not
being very clear with everyone about having done that.  And I don't know
enough about Git to know if this is even possible nor exactly how it
works.  I do know you're never supposed to edit history that's already
been published.  But this example is a little trickier because it might
be like deleting a file, pushing that commit, creating the file again,
and pushing that commit.  History is not being altered in this case.

Anyway, my guess would be that something changed with GitHub's
implementation.  Either way, though, it sounds like it would be good to
figure out what caused the change.  But again, it seems that usually the
generated archive file based on the tag is stable (i.e., the hash is
always the same).

> I believe the original issue raised by John was about the difference
> between the upstream site release tarballs and the files available
> on Github. Since I don’t see any of the release-release links on
> github.com/bitcoin/bitcoin/, I assume the developer didn’t bother
> to upload the existing binary files, but rather relied on Github
> pre-creating the files based on Git tags, hence a different gzip/tar
> rendition.

That could be, but it could also be that the developer created the tag
and pushed to GitHub, then downloaded the GitHub archive of that tag and
made that the release file available as a static file on the Bitcoin
website, and then later the GitHub archive generation implementation
changed, thus producing an archive with a different hash.  (Or some
variant of that.  For example, GitHub could cache generated archive
files, so it could serve from the cache for a long time, but then if the
cached file gets deleted, then when it gets generated again, if there's
some creation-time timestamp erroneously ending up in the archive, the
hash will change.  It would be great to know if one of GitHub's goals
for the generation is an identical hash.)

Lewis