<https://github.blog/2023-02-21-update-on-the-futu...
# random
e
@broad-processor-92400 that means the fix I just did for you over in Pex will have lockfiles that eventually go bad!
w
we deployed Git 2.38 to the service that powers source downloads
we recommend you switch to release assets
Am I understanding this correctly, this change ONLY affects(ed) downloaded zipped source code? Not release'd assets? As in, those assets are forever immutable? Because I was about to say how out-of-touch this change felt, without realizing they seemed to only be talking about source code. I haven't seen as many cases of source code zip hashes in the wild, at least.
e
Yes, only zip / tar.gz magic download source tarball URLs. Although I think tar.gz may not be affected.
I mean, if GitHub messed with your released assets - which are opaque to them - that would be an Orwellian attack.
w
Exactly, mind was blown on first read - and progressively reassembled itself when I realized we're talking source
p
Yes, only zip / tar.gz magic download source tarball URLs. Although I think tar.gz may not be affected.
When they made the change (until they reverted it), it broke a few tar.gz source downloads for me until they reverted. Sadly I can’t remember what.
b
that means the fix I just did for you over in Pex will have lockfiles that eventually go bad!
Yeah, it would. Fortunately, we were just using them for temporary fixes while we wait for upstream to merge/release. (And using the
git+...
urls works fine too.)
b
Yeah I got hit by this as well with a .tar.gz
I'm surprised they're sticking to their guns here. One of the major complainers of this change was Bazel users, who also pin URL+SHA. And there's tons of those...