News for hackers. Stuff that matters.
Re:Git archive checksums may change by ErikCorry on Monday January 30, 2023 @05:31PM (#34587457)
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?

Re:Git archive checksums may change by IanCal on Monday January 30, 2023 @05:47PM (#34587708)
I think the reproducible build part is about projects that depend on these outputs. The goal is ensuring you and I have both pulled exactly the same dependencies.
Re:Git archive checksums may change by blueflow on Monday January 30, 2023 @05:55PM (#34587805)
1) SHA-256 is reasonably secure

2) The checksum assures you that the file you have is the same your upstream looked at

Re:Git archive checksums may change by ErikCorry on Tuesday January 31, 2023 @03:31AM (#34592728)
1) Ah of course, this is SHA256, my mistake.

2) If I and the upstream are both looking at a file that was generated by Github then the Sha may match, but that doesn't prove we weren't both owned by Github.

Perhaps what I am missing is that this isn't part of a reproducible build scenario. There's no attempt to ensure that the file Github had built is the one I would build with the same starting point.

Re:Git archive checksums may change by blueflow on Tuesday January 31, 2023 @05:57AM (#34593672)
If you trust your upstream, then the checksum is enough. If you don't trust your upstream, its sort of an RCE anyways.
Re:Git archive checksums may change by ajross on Monday January 30, 2023 @06:09PM (#34587983)
> Firstly SHA is not a secure hash.

It's... literally the Secure Hash Algorithm. (Yes, yes, SHA-1 was broken a while back, but SHA and derivatives were absolutely intended to provide secure collision resistance).

I think you're mixing things up here. Github didn't change the SHA-1 commit IDs in the repositories[1]. They changed the compression algorithm used for (and thus the file contents of) "git archive" output. So your tarballs have the same unpacked data but different hashes under all algorithms, secure or not.

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

Indeed. So you take and record a SHA-256 of the archive file you are tagging such that no one can feasibly do that!

Again, what's happened here is that the links pointing to generated archive files that projects assumed were immutable turned out not to be. It's got nothing to do with security or cryptography.

[1] Which would be a whole-internet-breaking catastrophe, of course. They didn't do that and never will.

Re:Git archive checksums may change by chlorion on Monday January 30, 2023 @07:06PM (#34588688)
>Firstly SHA is not a secure hash.

This is incorrect, but even if it were true, you could use whatever your hash of choice is instead. Gentoo for example can use whatever hash you like, such as blake2, and the default Gentoo repo captures both the sha512 and blake2 digests in the manifest.