by JamesCoyne on 2/2/23, 6:47 PM with 76 comments
by pcj-github on 2/2/23, 10:05 PM
by skywal_l on 2/2/23, 9:34 PM
1. You can't just rely on documentation ("we never said we would guarantee this or that") to push back on your users' claims that you introduced a breaking change. If you care more about your documentation than your users, they will turn their back on you.
2. However if you start guaranteeing too much stability, innovation and change will become too costly or even impossible. In this instance, if the git team has to guarantee their hashes (which seems impossible anyway because it depends on the external gzip program) then they can never improve on compression.
Tough situation to be in.
by mjw1007 on 2/3/23, 8:06 AM
But this is an example of a much weaker proposition: if you don't document your contract, then people will guess what the contract is and some of them will guess wrong.
(In fact in this case it seems it's more like "if you don't document your contract and your support staff sometimes say the behaviour is A, people will rely on the behaviour being A".)
by vlovich123 on 2/3/23, 5:06 AM
Checksums still work and protect against malicious tarballs which are generally riskier to unpack than plain steam compression / decompression. The server and client gets the smaller file transfers and compression improvements can evolve transparently by negotiating the transfer encoding. The server can still cache the encoded form to avoid needing to compress the same file repeatedly.
Seems like a win win solution without requesting a drastic redesign of package managers everywhere and everyone walks away having won the properties of the system they value.
by jancsika on 2/3/23, 2:42 AM
Didn't Google beat Hyrum's law by using their weight to force middleboxes to accept some variation in some datum of an http header or something?
Edit: hint: something about rotating a value for some number of decades. Either forcing the hand of middleboxes or CAs, I can't remember. In either case, it seemed like a real pain in the ass to keep the API observability concrete from hardening. :)
by cratermoon on 2/3/23, 2:18 AM
I'm certain there's some exploit waiting to subvert the decompress algorithm and substitute malicious content in place of the actual archive files.
by DelightOne on 2/3/23, 12:00 AM
by AJRF on 2/3/23, 2:51 AM
I think this just made me realise an issue I was having with Swift Package Manager a few months back. We have a bunch of ObjC frameworks in our app that we don't want people to update anymore so we can rewrite them, and we just threw them all into a big umbrella project, but for some reason we couldn't get the binary target URL from Github Enterprise to work on our self hosted Enterprise instance because the checksum would be different every time, but it worked perfectly for Github Cloud.
Is there anyone from Github here - Can you confirm that is the cause of issue for GH Enterprise?
by travisgriggs on 2/2/23, 9:22 PM
by meling on 2/3/23, 4:57 AM
by avgcorrection on 2/2/23, 10:39 PM
by syntheticnature on 2/2/23, 8:36 PM
by jmclnx on 2/2/23, 8:27 PM
I cannot help but wonder if this change was forced upon github by Microsoft because gzip is GPL 3, maybe this other version is a clean room clone. We all know corporations hate GPLv3, including the large corporation I work for.