5 ms·

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 sig

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.

ArchOversight 4y ago
a git checkout of the code at that particular tag hasn't changed. Just the tarball that git archive generates has.
- vlovich123 4y ago
  The two main problems are: A) How do you catch tarballs that have extra files injected that aren't part of your manifest B) What does the performance of this look like? Certainly for traditional HDDs this is going to kill performance, but even for SSDs I think verifying a bunch of small files is going to be less efficient than verifying the tarball.
  - ArchOversight 4y ago
    A wouldn't be an issue since you are checking out a git tag. B would just be a normal git checkout, which already validates that all the objects are reachable and git tags (and commits for that matter) can be signed, and since the sha1 hash is signed as well it validates that the entire tree of commits has not been tampered with. So as long you trust git to not lie about what it is writing to disk, you have a valid checkout of that tag. And if you do expect it to lie, why do you expect tar to not lie about what it is unpacking?
    - vlovich123 4y ago
      I know GitHub had asked that clones from package manager use shallow clones. It wouldn't surprise me if downloading tarballs is similarly beneficial to GitHub because it's trivially cacheable in a CDN and thus lowers their operational footprint to support package managers.
  - ilyt 4y ago
    Well, the simplest way would be to make checksum after decompression, that doesn't need per file verify and relies on files being put in same order into tar file. The other method would be having Manifest file with checksum of every file inside the tar and compare that in-flight, could be simple "read from tar, compare to hash, write to disk" (with maybe some tmpfiles for the bigger ones)
    - vlovich123 4y ago
      It’s not just about the integrity of the files you’re processing, but also the integrity of the archive itself. If you extract the tarball from a random place, there’s a larger security risk. Now granted HTTPS probably mitigates a lot of it, but cert pinning isn’t that common so MITM attacks aren’t thaaat theoretical.
      - ilyt 4y ago
        You can do validation in flight during extraction. Signed file manifests are how distros like Debian did it since forever, althought in their cases its two step process, the packages themselves contain their own signature and whole directory tree also gets signed (to avoid shenaningans like "attacker putting older, still vulnerable, but signed version into the repo)
- duped 4y ago
  Ok, now guarantee that.
ErikCorry 4y ago
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?
- IanCal 4y ago
  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.
- blueflow 4y ago
  1) SHA-256 is reasonably secure 2) The checksum assures you that the file you have is the same your upstream looked at
  - ErikCorry 4y ago
    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.
    - blueflow 4y ago
      If you trust your upstream, then the checksum is enough. If you don't trust your upstream, its sort of an RCE anyways.
- ajross 4y ago
  > 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.
Denvercoder9 4y ago
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.
- bentley 4y ago
  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.
  - shakow 4y ago
    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.
    - bentley 4y ago
      > 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.
    - viraptor 4y ago
      The certificate guarantees the source of the file, not the trust you should put in its contents. I can upload malware as a github project release file and https doesn't change that you shouldn't download/run it. For software distribution this actually sometimes goes the other way - debian/ubuntu uses http (no s) for their packages, because the content itself is signed by the distribution and this way you can easily cache it at multiple levels.
shakow 4y ago
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.
- catiopatio 4y ago
  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.
  - Denvercoder9 4y ago
    > 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.
    - ilyt 4y ago
      The problem was people assuming github works like that - saves a archive of every commit, which is obviously silly if you think about it (why save it if you can regenerate it on a whim from any commit you want?)
    - account42 4y ago
      > That workflow is still perfectly fine with GitHub It would be perfectly fine if you could prevent GitHub from linking the autogenerated archives from the releases or at least distinguish them in a way that makes it clear that they are not immutable maintainer-generated archives.
  - 4y ago

ArchOversight 4y ago

a git checkout of the code at that particular tag hasn't changed. Just the tarball that git archive generates has.

vlovich123 4y ago
The two main problems are: A) How do you catch tarballs that have extra files injected that aren't part of your manifest B) What does the performance of this look like? Certainly for traditional HDDs this is going to kill performance, but even for SSDs I think verifying a bunch of small files is going to be less efficient than verifying the tarball.
- ArchOversight 4y ago
  A wouldn't be an issue since you are checking out a git tag. B would just be a normal git checkout, which already validates that all the objects are reachable and git tags (and commits for that matter) can be signed, and since the sha1 hash is signed as well it validates that the entire tree of commits has not been tampered with. So as long you trust git to not lie about what it is writing to disk, you have a valid checkout of that tag. And if you do expect it to lie, why do you expect tar to not lie about what it is unpacking?
  - vlovich123 4y ago
    I know GitHub had asked that clones from package manager use shallow clones. It wouldn't surprise me if downloading tarballs is similarly beneficial to GitHub because it's trivially cacheable in a CDN and thus lowers their operational footprint to support package managers.
- ilyt 4y ago
  Well, the simplest way would be to make checksum after decompression, that doesn't need per file verify and relies on files being put in same order into tar file. The other method would be having Manifest file with checksum of every file inside the tar and compare that in-flight, could be simple "read from tar, compare to hash, write to disk" (with maybe some tmpfiles for the bigger ones)
  - vlovich123 4y ago
    It’s not just about the integrity of the files you’re processing, but also the integrity of the archive itself. If you extract the tarball from a random place, there’s a larger security risk. Now granted HTTPS probably mitigates a lot of it, but cert pinning isn’t that common so MITM attacks aren’t thaaat theoretical.
    - ilyt 4y ago
      You can do validation in flight during extraction. Signed file manifests are how distros like Debian did it since forever, althought in their cases its two step process, the packages themselves contain their own signature and whole directory tree also gets signed (to avoid shenaningans like "attacker putting older, still vulnerable, but signed version into the repo)
duped 4y ago
Ok, now guarantee that.

ErikCorry 4y ago

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?

IanCal 4y ago
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.
blueflow 4y ago
1) SHA-256 is reasonably secure 2) The checksum assures you that the file you have is the same your upstream looked at
- ErikCorry 4y ago
  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.
  - blueflow 4y ago
    If you trust your upstream, then the checksum is enough. If you don't trust your upstream, its sort of an RCE anyways.
ajross 4y ago
> 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.

Denvercoder9 4y ago

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.

bentley 4y ago
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.
- shakow 4y ago
  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.
  - bentley 4y ago
    > 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.
  - viraptor 4y ago
    The certificate guarantees the source of the file, not the trust you should put in its contents. I can upload malware as a github project release file and https doesn't change that you shouldn't download/run it. For software distribution this actually sometimes goes the other way - debian/ubuntu uses http (no s) for their packages, because the content itself is signed by the distribution and this way you can easily cache it at multiple levels.

shakow 4y ago

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.

catiopatio 4y ago
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.
- Denvercoder9 4y ago
  > 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.
  - ilyt 4y ago
    The problem was people assuming github works like that - saves a archive of every commit, which is obviously silly if you think about it (why save it if you can regenerate it on a whim from any commit you want?)
  - account42 4y ago
    > That workflow is still perfectly fine with GitHub It would be perfectly fine if you could prevent GitHub from linking the autogenerated archives from the releases or at least distinguish them in a way that makes it clear that they are not immutable maintainer-generated archives.
- 4y ago