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

121–130 of 255 posts

Re: Git archive checksums may change

#121

Post by bentley »

JoshTriplett wrote: post #112
bentley wrote: post #100

Earlier quoted context omitted.

Sadly there has been a sharp uptick in software that provides no release tarballs anymore. With the rise of GitHub many upstreams choose to make a tag and let people download the autogenerated tarballs, despite the fact that they won’t contain preprocessed autoconf or (more importantly) any Git submodules. The situation is deteriorating further as some projects make no releases at all, assuming users will add the pro…

> many upstreams choose to make a tag and let people download the autogenerated tarballs Which is fine as long as you rely on the hash of the tag rather than the hash of the tarball. > despite the fact that they won’t contain preprocessed autoconf This is a feature; run `autoreconf -vfi` at build time, so that you don't depend on the maintainer's idiosyncratic autotools setup and local macros, and so that you can rel…

> This is a feature; run `autoreconf -vfi` at build time, so that you don't depend on the maintainer's idiosyncratic autotools setup and local macros, and so that you can reliably regenerate it all if you want to change configure.ac or Makefile.am.

On a package bulk build machine, that’s a lot (like, a lot) of wasted CPU cycles multiplied by the thousands of packages that use autoconf. For the majority of packages that don’t patch configure.ac or Makefile.am, it’s nicer to use a preprocessed tarball and check that you can reproduce the same autoconf output when adding the package to the package manager, because then it only happens once.

Re: Git archive checksums may change

#122

Post by catiopatio »

shakow wrote: post #111
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.

By checking the hash of the extracted files. The hash of the archive is dependent on the order in which the file were compressed, the compression, some metadata, etc.

That’s expensive, complicated, exposes a greater attack surface, and requires new tooling to maintain considerably more complex metadata covering the full contents of source archives.

For the entire multi-decade history of open source, the norm has been — for very good reason — that source archives are immutable and will not change.

The solution here isn’t to change the entire open source ecosystem.

Re: Git archive checksums may change

#123

Post by rsc »

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

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 chain security, and it can lead here too. Once GitHub has served an archive with a given checksum, it should guarantee that the archive has that checksum forever.

Re: Git archive checksums may change

#124

Post by jkachmar »

pxc wrote: post #88
frankjr wrote: post #5

GitHub will need to revert this change. They've just crippled pretty much every "from source" package manager out there.

Nixpkgs' so-called binary cache actually also caches source tarballs. Any Nix users out there who ran updates during the change? Did cache hits save you? Did cache misses break your builds?

didn’t realize this had happened until i logged off of my work computer & saw someone had shared this thread in a group chat.

looks like we were completely unaffected, as no one made any updates to derivations referencing GitHub sources in a way that invalidated old entries (i.e. no version bumps, new additions, etc.).

Re: Git archive checksums may change

#125

Post by bentley »

shakow wrote: post #113
bentley wrote: post #103

Earlier quoted context omitted.

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.

But then that's the role of the httpS query with which you will fetch your data. And if you don't trust your http layer and/or Github's certificate, then you should not trust their archive anyway.

> And if you don't trust your http layer and/or Github's certificate, then you should not trust their archive anyway.

The nice thing about checksumming the tarball is that once you’ve done so, it doesn’t matter whether you trust GitHub or the HTTPS layer or not.

GitHub and its HTTPS cert provide no protection against a compromised project re‐tagging a repo with malicious source, or even deleting and re‐uploading a stable release tarball with something malicious.

Re: Git archive checksums may change

#126

Post by anderskaseorg »

pxc wrote: post #88
frankjr wrote: post #5

GitHub will need to revert this change. They've just crippled pretty much every "from source" package manager out there.

Nixpkgs' so-called binary cache actually also caches source tarballs. Any Nix users out there who ran updates during the change? Did cache hits save you? Did cache misses break your builds?

Nixpkgs’s fetchFromGitHub function hashes the contents of GitHub archives after unpacking, so it’s unaffected.

Re: Git archive checksums may change

#127

Post by Denvercoder9 »

catiopatio wrote: post #122
shakow wrote: post #111

Earlier quoted context omitted.

By checking the hash of the extracted files. The hash of the archive is dependent on the order in which the file were compressed, the compression, some metadata, etc.

That’s expensive, complicated, exposes a greater attack surface, and requires new tooling to maintain considerably more complex metadata covering the full contents of source archives. For the entire multi-decade history of open source, the norm has been — for very good reason — that source archives are immutable and will not change. The solution here isn’t to change the entire open source ecosystem.

> For literally the entire multi-decade history of open source, the norm has been — for very good reason — that source archives are immutable and will not change.

Well, the norm has been that maintainers generated and distributed a source archive, and that archive being immutable. That workflow is still perfectly fine with GitHub and not impacted by this change.

The problem is that a bunch of maintainers stopped generating and distributing archives, and instead started relying on GitHub to automatically do that for them.

Re: Git archive checksums may change

#128

Post by VWWHFSfQ »

mdouglass wrote: post #108
andrewguenther wrote: post #107

Earlier quoted context omitted.

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

Most likely a caching layer at GitHub still has the pre-rollback archive.

Re: Git archive checksums may change

#129

Post by bentley »

catiopatio wrote: post #122
shakow wrote: post #111

Earlier quoted context omitted.

By checking the hash of the extracted files. The hash of the archive is dependent on the order in which the file were compressed, the compression, some metadata, etc.

That’s expensive, complicated, exposes a greater attack surface, and requires new tooling to maintain considerably more complex metadata covering the full contents of source archives. For the entire multi-decade history of open source, the norm has been — for very good reason — that source archives are immutable and will not change. The solution here isn’t to change the entire open source ecosystem.

Indeed. I remember when Canonical was heavily pushing bzr and others were big fans of Mercurial. Glad my package manager maintainers didn’t waste time writing infrastructure to handle those projects at the repository level. Nobody had to, because providing source tarballs was the norm.

Re: Git archive checksums may change

#130

Post by ZephyrBlu »

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.

You just described >90% of users. Everyone does this for something, most people do it for most things.

You minimally read the docs, get something working and then leave it alone. Of course you're going to be pissed off when an implicit assumption which has been stable for a long time is broken.

Post reply on HN