5 ms·

The git repository has been scanned by many eyes. People, other than the authors, do read the source code on GitHub or clone/fork the repo and try to build / mo

The git repository has been scanned by many eyes. People, other than the authors, do read the source code on GitHub or clone/fork the repo and try to build / modify when they want to contribute. By contrast, almost no one reads through the tarball contents. They just assume that it is essential the same as the git repo.

badsectoracula 3y ago
That doesn't make the Git repository inherently more authoritative or trustworthy, not to mention that if you do not trust the tarballs you shouldn't trust the Git repository either - or the developers who control what goes in both. The issue here isn't about trusting Git or tarballs, is about trusting developers. If you do not trust the developers then getting the code via Git or tarball wouldn't make anything more trustworthy and if you DO trust the developers then there is no reason to trust the Git more than the tarballs since they are both provided by the same people who you already trust to not insert malicious code in the project.
- bdd8f1df777b 3y ago
  That's the conventional thinking, but it has been proven false by this xz incidence. The maintainer of xz did not inject any malicious code into the git repo, but only in the tarball, exactly because the latter is subject to far fewer eyes and he took far less risks polluting only the tarball.
  - badsectoracula 3y ago
    The project was already compromised, the Git repository isn't any more trustworthy than the tarball. And if there is any relevant lesson from the xz case isn't to trust Git more than tarballs but - as someone else mentioned already - tarballs should be fully reproducible from Git.
    - bdd8f1df777b 3y ago
      > The project was already compromised, the Git repository isn't any more trustworthy than the tarball. You are talking about this from hindsight. For other projects, we do not know yet if anything similar is happening. So for them the Git repo is definitely more trustworthy. > tarballs should be fully reproducible from Git. That's exactly the same as trusting Git repo more than the tarball.

badsectoracula 3y ago

That doesn't make the Git repository inherently more authoritative or trustworthy, not to mention that if you do not trust the tarballs you shouldn't trust the Git repository either - or the developers who control what goes in both. The issue here isn't about trusting Git or tarballs, is about trusting developers. If you do not trust the developers then getting the code via Git or tarball wouldn't make anything more trustworthy and if you DO trust the developers then there is no reason to trust the Git more than the tarballs since they are both provided by the same people who you already trust to not insert malicious code in the project.

bdd8f1df777b 3y ago
That's the conventional thinking, but it has been proven false by this xz incidence. The maintainer of xz did not inject any malicious code into the git repo, but only in the tarball, exactly because the latter is subject to far fewer eyes and he took far less risks polluting only the tarball.
- badsectoracula 3y ago
  The project was already compromised, the Git repository isn't any more trustworthy than the tarball. And if there is any relevant lesson from the xz case isn't to trust Git more than tarballs but - as someone else mentioned already - tarballs should be fully reproducible from Git.
  - bdd8f1df777b 3y ago
    > The project was already compromised, the Git repository isn't any more trustworthy than the tarball. You are talking about this from hindsight. For other projects, we do not know yet if anything similar is happening. So for them the Git repo is definitely more trustworthy. > tarballs should be fully reproducible from Git. That's exactly the same as trusting Git repo more than the tarball.