Live data from Hacker News

Git archive checksums may change

github.blog

251–255 of 255 posts

Re: Git archive checksums may change

#251

Earlier quoted context omitted.

That's my thought as well. They could also potentially retroactively generate the source tarballs using the old method for every possible repository/tag on Github, store it, and serve that, and then only generate it on-demand for new tags, but I doubt they'll do that. They might though, given this is what led to the problem in the first place (ie; the on-demand generation vs generating on push+storing).

That seems wasteful. Many projects do not actively advertise the GitHub tag downloads, and instead have their own stored and stable tarballs (or other distributions). And I suppose many users of those auto-generated downloads don’t care about their checksums.

The solution is simple: for a monthly payment of $1 per gigabyte the downloads are stable. Otherwise they are not.

Re: Git archive checksums may change

#252
post #123

Hey folks. I'm the product manager for Git at GitHub. We're sorry for the breakage, we're reverting the change, and we'll communicate better about such changes in the future (including timelines). Also posted here: https://github.com/bazel-contrib/SIG-rules-authors/issues/11...

Thanks for the quick rollback. I want to encourage you to think about locking in the current archive details, at least for archives that have already been served. Verifying that downloaded archives have the expected checksum is a critical best practice for software supply chain security. Training people to ignore checksum changes is training them to ignore attacks. GitHub is a strong leader in other parts of supply c…

https://floxdev.com/blog/hash-collision

Re: Git archive checksums may change

#253

Earlier quoted context omitted.

That seems wasteful. Many projects do not actively advertise the GitHub tag downloads, and instead have their own stored and stable tarballs (or other distributions). And I suppose many users of those auto-generated downloads don’t care about their checksums.

The solution is simple: for a monthly payment of $1 per gigabyte the downloads are stable. Otherwise they are not.

Who should pay for this? The developer of the project might not care about the stability, but the maintainers of the various Linux distros might. Should the developer pay from their own pocket to make the Linux folks happy? Should there be some pool of all the Linux distros to collect the fees and pay for these projects?

Re: Git archive checksums may change

#254
post #9

Earlier quoted context omitted.

I prefer that tool be adapted to be more resilient and not depend on github particular implementation.

the change was to git, not GitHub.

Sorry, I missread the Github annonce and incorrectly interpreted it.

Re: Git archive checksums may change

#255

Earlier quoted context omitted.

That norm still exists, and it's offered by Github in form of Github Releases feature as well. It's the downstream tooling ( i.e. all the builds and package managers ) that need to clean their act up.

If the source tar changes, how do you propose the downstream tooling distinguishes between data corruption, MITM attack and upstream deciding to change the number without notifying anyone?

That's the whole point, source tars when properly versioned don't change. And you can get unchanged versions from any mirror in the world. sha256 of linux-2.6.10 release is 404e33da7c1bf271e0791cd771d065e19a2b1401ef8ebb481a60ce8ddc73e131, it wont change
Post reply on HN