Git archive checksums may change

Post by groestl » Mon, Jan 30, 2023, 10:44 PM UTC

jzelinskie wrote: post #46

Does anyone have the motivation for why the git project wants to use their own implementation of gzip? Did this implementation already exist and was being used for something else? I understand wanting fewer dependencies, but gut-reaction is that it's a bad move in the unsafe world of C to rewrite something that already has a far more audited, ubiquitous implementation.

Post by IanCal » Mon, Jan 30, 2023, 10:47 PM UTC

ErikCorry wrote: post #34

swarfield wrote: post #10

Earlier quoted context omitted.

Using SHA hashes when building guarantees that the code that you are building is what you think it is. How else would you verify dependencies like this, GPG signatures would have the same issue if you change the underlying bits.

This seems like a weak argument. Firstly SHA is not a secure hash. Secondly if your build step involves uploading data to a third party then allowing them to transform it as they see fit and then checksumming the result then it's not really a reproducible build. For all you know, Github inserts a virus during the compression of the archive. What am I missing?

Post by dharmab » Mon, Jan 30, 2023, 10:50 PM UTC

phphphphp wrote: post #32

vtbassmatt wrote: post #27

Earlier quoted context omitted.

We updated our Git version which made this change for the reasons explained. At the time we didn't foresee the impact. We're quickly rolling back the change now, as it's clear we need to look at this more closely to see if we can make the changes in a less disruptive way. Thanks for letting us know.

Consumers often mistake hasn’t changed for a commitment to never change: any sufficiently large product will be littered with these kind of implicit commitments made by the product to consumers that nobody has visibility into. You’re unfortunate that we were all relying on this commitment you’ve never made, but the quick reversion is the best we can hope for. People will theorise how this could have been avoided but…

Post by nemetroid » Mon, Jan 30, 2023, 10:51 PM UTC

jzelinskie wrote: post #46

Does anyone have the motivation for why the git project wants to use their own implementation of gzip? Did this implementation already exist and was being used for something else? I understand wanting fewer dependencies, but gut-reaction is that it's a bad move in the unsafe world of C to rewrite something that already has a far more audited, ubiquitous implementation.

Post by groestl » Mon, Jan 30, 2023, 10:53 PM UTC

kentonv wrote: post #25

acdha wrote: post #15

Earlier quoted context omitted.

If those tools incorrectly assume an API contract which doesn't exist, isn't the right answer to fix those tools?

In theory, sure, that's what we'd do in an ideal world. In the real world it will take millions of dollars of eng labor just to update the hashes to fix everything that's currently broken and millions more to actually implement something better and move everyone over to it. This isn't worth it, GitHub needs to just revert the change and then engineer a way to keep hashes stable going forward.