Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git archive checksums may change

github.blog

Post reply on HN
Print view View original

101–110 of 255 posts

Re: Git archive checksums may change

#101

Post by dataflow »

blueflow wrote: post #45
vlovich123 wrote: post #17

Hyrum's Law strikes again. It kind of doesn't matter what you document. If you weren't randomizing your checksum previously [1], you can't just spring this on the community and blame it for the fallout. I'm more shocked that there's resistance from the GitHub team saying "but we documented this isn't stable". Default stance for the team should be rollback & reevaluate an alternate path forward when the scope is this…

But look at it from the other side. Users that don't read your documentation and expect your software to work like they imagined are just a huge pain in the ass.

I don't think expecting users to go look for a user manual on each website whose links they download from is a realistic expectation.

Re: Git archive checksums may change

#102

Post by jart »

thirtyseven wrote: post #79
jart wrote: post #18

Earlier quoted context omitted.

If they're using multiple URLs like a good Bazel user then they shouldn't be impacted.

The setup instructions for almost [1] every [2] major [3] rule set [4] only provide one (GitHub) url in the Starlark blob you're supposed to copy and paste, so hard to blame users here. [1] https://github.com/bazelbuild/rules_jvm_external/releases/ta... [2] https://github.com/bazelbuild/rules_python/releases/tag/0.17... [3] https://github.com/bazelbuild/rules_java/releases/tag/5.4.0 [4] https://github.com/bazelbuild/…

I agree. The Bazel developers failed in their leadership.

Re: Git archive checksums may change

#103

Post by bentley »

Denvercoder9 wrote: post #78
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.

I wouldn't check the hash of the compressed archive, but of the actual files themselves. It's a bit more metadata, but it's also a lot more robust, and allows you to detect changes after unpacking as well.

It’s generally a bad idea to process (extract) a tarball of unknown provenance. Verifying the tarball is from a known source beforehand mitigates the risk of, say, a malicious tarball that exploits a tar or gzip 0‐day.

Re: Git archive checksums may change

#104

Post by yakubin »

Now I’m having a laugh at all those times someone tried to explain to me that vendoring dependencies doesn’t make sense, when you have package managers which verify checksums of the things downloaded from GitHub/wherever. A good laugh.

Keep it simple, just vendor your deps.

Re: Git archive checksums may change

#105

Post by blueflow »

vlovich123 wrote: post #86
blueflow wrote: post #45

Earlier quoted context omitted.

But look at it from the other side. Users that don't read your documentation and expect your software to work like they imagined are just a huge pain in the ass.

Fact of life: the vast majority of your users do not read your documentation (or do not do so carefully enough that what you put in your docs is an ironclad proof that all users adhere to). That's literally what Hyrum's law is about. Of course, you can choose to do whatever you want. It's valuable to recognize of course that you're trading off good will from your users with whatever technical improvement is getting m…

Thats support you could expect if you paid for it.

Re: Git archive checksums may change

#106

Post by dataflow »

mr_toad wrote: post #70
blueflow wrote: post #45

Earlier quoted context omitted.

But look at it from the other side. Users that don't read your documentation and expect your software to work like they imagined are just a huge pain in the ass.

Give a man a fish and he’ll assume he’s entitled to a lifetime supply of free fish.

This has nothing to do with free vs. paid? The question is whether giving someone 99 of the same fish entitles them to expect the 100th one you throw in to be the same kind of fish, whether they paid for it or not.

Re: Git archive checksums may change

#107

Post by andrewguenther »

mdouglass wrote: post #98
vtbassmatt wrote: post #20

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...

We are seeing an npm install failure inside our docker builds pointing at a github URL with a SHA change. Is this possibly related? #15 [dev-builder 4/7] RUN --mount=type=secret,id=npm,dst=/root/.npmrc npm ci #0 4.743 npm WARN deprecated querystring@0.2.0: The querystring API is considered Legacy. new code should use the URLSearchParams API instead. #0 8.119 npm WARN tarball tarball data for http2@https://github.com/…

Yes, this is the exact issue being described

Re: Git archive checksums may change

#108

Post by mdouglass »

andrewguenther wrote: post #107
mdouglass wrote: post #98

Earlier quoted context omitted.

We are seeing an npm install failure inside our docker builds pointing at a github URL with a SHA change. Is this possibly related? #15 [dev-builder 4/7] RUN --mount=type=secret,id=npm,dst=/root/.npmrc npm ci #0 4.743 npm WARN deprecated querystring@0.2.0: The querystring API is considered Legacy. new code should use the URLSearchParams API instead. #0 8.119 npm WARN tarball tarball data for http2@https://github.com/…

Yes, this is the exact issue being described

That's what I thought, but I assumed with the rollback an hour plus ago, it wouldn't still be happening. That was off a build just a few minutes ago (actually repeated it in between the time I posted my original message and this reply and it happened again).

Re: Git archive checksums may change

#109

Post by jeffbee »

groestl wrote: post #75
VWWHFSfQ wrote: post #38

Earlier quoted context omitted.

At this point they'll be stuck on old git for all of eternity unless they just roll their own archive/compress step out of band so the old hashes still work. Yikes.

They could also brownout the implied contract over a longer timespan.

They could use the old behavior for archives in which all the inputs predate the changeover.

Re: Git archive checksums may change

#110

Post by blueflow »

dataflow wrote: post #101
blueflow wrote: post #45

Earlier quoted context omitted.

But look at it from the other side. Users that don't read your documentation and expect your software to work like they imagined are just a huge pain in the ass.

I don't think expecting users to go look for a user manual on each website whose links they download from is a realistic expectation.

Worse, you can't expect other people to host your data for free, forever. If you want your data distributed, you need to check first if the platform is suitable for your purposes.
Post reply on HN