4 ms·

Why are tarballs any less authoritative than a Git repository? Both come from the same authors. If you can't trust the tarball released by some author why would

Why are tarballs any less authoritative than a Git repository? Both come from the same authors. If you can't trust the tarball released by some author why would you trust what the repository contains?

senectus1 3y ago
as i understand it, the tooling would "see" some of the questionable configs that were in the tarballs. Because they're packaged into tarballs they cant be checked. or or to the point they use the tarballs because its much faster...
- badsectoracula 3y ago
  What tooling? Git is just a filesystem with file versions, anything you can check in a tarball can also be checked in Git. The only thing Git adds is a change history for the contents in the filesystem (a history that can be forged too - Git even has a bunch of commands for that too). If you cannot trust the authors' tarballs how can you trust their Git repository?
Terr_ 3y ago
> Why are tarballs any less authoritative than a Git repository? Both come from the same authors. Traceability. There's a difference in how easily someone can insert nefarious code without it going through processes that might reveal or stop it. Compare: "Why is a paper sack of pills any different than a factory-sealed anti-tamper bottle? You're buying them from the same grocery store..."
- badsectoracula 3y ago
  > Traceability. There's a difference in how easily someone can insert nefarious code without it going through processes that might reveal or stop it. But both come from the same authors. If you do not trust the tarball because it may have nefarious how would you trust Git to not have nefarious code? The authors have complete control over what goes in Git and what processes might be there. > Compare... The grocery store comparison doesn't fit here because grocery stores do not make the things they sell. The equivalent to a grocery store would be the download site (BTW lets not continue with metaphors because IMO instead of making things more clear you are introducing TWO parallel channels to argue about).
  - grumbel 3y ago
    > But both come from the same authors. The Git repository comes with a history containing each and every commit, along with checksums and sometimes cryptographic signatures for it all. The tarball is just a bunch of random files. If somebody wants to rewrite the Git history, that will get instantly noticed by anybody that had an older clone of it. If somebody adds a hack to it, it will be at the top of the history and easy to notice as well. If somebody adds something to a tarball, there is nothing to tell you that something changed, you'll have to audit the whole thing from top to bottom (or compare it to the Git repository it came from). Also the author isn't in control here, the tarball can get changed after it was uploaded to the server and there would be nothing in the tarball itself to tell you. People are using PGP signatures and checksums to secure tarballs some more, but that's always an extra step and doesn't happen automatically. And even that still doesn't give you the history.
    - badsectoracula 3y ago
      > The tarball is just a bunch of random files. But that is EXACTLY WHAT GIT IS!, the only difference is that you also get the previous versions too. That doesn't help you at all when the authors themselves are not trustworthy. It MAY help after finding a compromise to figure out when it happened, but it wont help anyone prevent it. What you write is about someone trying to compromising the Git server itself. This is NOT what i refer to (and even that sort of compromise would be sidestepped with signed tarballs). What i refer to is more fundamental: the author of the project controls what is put in the Git repository itself, just like the tarballs. The Git repository is NOT any more trustworthy than the tarballs: if you do not trust the latter then you should not trust the former either and if you do trust the former then there is no reason to not trust the latter.
      - grumbel 3y ago
        > the author of the project controls what is put in the Git repository itself The author doesn't control the Git repository. The Git repository is a shared data structure, not just bits on a server. Neither the author nor anybody else can just change the Git repository arbitrarily. They can only change it in ways allowed by Git or the alarm bells will be going off. A tarball has no such restrictions.
- xorcist 3y ago
  This backdoor resided in git for a year without anyone noticing. It wasn't until it was activated via the tarball that someone found out. One could easily argue that signed tarballs are more vetted than git commits.
watt 3y ago
Every commit in git repository is effectively signed by the commit hash. You can't sneak in any unreviewed changes.
- badsectoracula 3y ago
  But you can sneak in reviewed (by you) changes, if you have control over the repository. Again: both the Git and the tarballs are released by the same developers.
  - kijin 3y ago
    You never have full control over a repository that can be cloned by others. Sure, you can rewrite the history, but anyone who has been pulling from your repo will notice the conflict. Whether you can trust the developer is beside the point. The question is how easily we can tell if someone is (still) trustworthy. Source control brings a measure of accountability into the game, making it more difficult for unusual activity to go undetected.
    - badsectoracula 3y ago
      It is not beside the point, it is the ENTIRE point. If you do not trust the developer then Git wont help you, the developer can put their malicious code in the repository itself. Git wont help you prevent anything, it is just a bunch of random files (as someone mentioned above) with the only difference being that there is a change history attached. But that wont prevent anyone with proper legitimate access (i.e. not trying to compromise it) to the repository from adding malicious code. All it may help with is figuring out, after the fact (of finding the compromise) when it was added. As i wrote above, the Git repository is not any more trustworthy than the tarballs: if you do not trust the latter then you should not trust the former either and if you do trust the former then there is no reason to not trust the latter.
      - kijin 3y ago
        > Git wont help you prevent anything Of course. Nothing does. > All it may help with is figuring out, after the fact (of finding the compromise) when it was added. Exactly. And that's what I'm trying to say. Ease of detection discourages bad behavior, just as regular police patrols help reduce crime in a neighborhood. With a public git repo, every commit increases the chance of detection long before a tarball is ready for release. I never said that I trust the git repo. I trust the eyeballs more, and the pitchforks too.
bdd8f1df777b 3y ago
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.

senectus1 3y ago

as i understand it, the tooling would "see" some of the questionable configs that were in the tarballs. Because they're packaged into tarballs they cant be checked. or or to the point they use the tarballs because its much faster...

badsectoracula 3y ago
What tooling? Git is just a filesystem with file versions, anything you can check in a tarball can also be checked in Git. The only thing Git adds is a change history for the contents in the filesystem (a history that can be forged too - Git even has a bunch of commands for that too). If you cannot trust the authors' tarballs how can you trust their Git repository?

Terr_ 3y ago

> Why are tarballs any less authoritative than a Git repository? Both come from the same authors. Traceability. There's a difference in how easily someone can insert nefarious code without it going through processes that might reveal or stop it. Compare: "Why is a paper sack of pills any different than a factory-sealed anti-tamper bottle? You're buying them from the same grocery store..."

badsectoracula 3y ago
> Traceability. There's a difference in how easily someone can insert nefarious code without it going through processes that might reveal or stop it. But both come from the same authors. If you do not trust the tarball because it may have nefarious how would you trust Git to not have nefarious code? The authors have complete control over what goes in Git and what processes might be there. > Compare... The grocery store comparison doesn't fit here because grocery stores do not make the things they sell. The equivalent to a grocery store would be the download site (BTW lets not continue with metaphors because IMO instead of making things more clear you are introducing TWO parallel channels to argue about).
- grumbel 3y ago
  > But both come from the same authors. The Git repository comes with a history containing each and every commit, along with checksums and sometimes cryptographic signatures for it all. The tarball is just a bunch of random files. If somebody wants to rewrite the Git history, that will get instantly noticed by anybody that had an older clone of it. If somebody adds a hack to it, it will be at the top of the history and easy to notice as well. If somebody adds something to a tarball, there is nothing to tell you that something changed, you'll have to audit the whole thing from top to bottom (or compare it to the Git repository it came from). Also the author isn't in control here, the tarball can get changed after it was uploaded to the server and there would be nothing in the tarball itself to tell you. People are using PGP signatures and checksums to secure tarballs some more, but that's always an extra step and doesn't happen automatically. And even that still doesn't give you the history.
  - badsectoracula 3y ago
    > The tarball is just a bunch of random files. But that is EXACTLY WHAT GIT IS!, the only difference is that you also get the previous versions too. That doesn't help you at all when the authors themselves are not trustworthy. It MAY help after finding a compromise to figure out when it happened, but it wont help anyone prevent it. What you write is about someone trying to compromising the Git server itself. This is NOT what i refer to (and even that sort of compromise would be sidestepped with signed tarballs). What i refer to is more fundamental: the author of the project controls what is put in the Git repository itself, just like the tarballs. The Git repository is NOT any more trustworthy than the tarballs: if you do not trust the latter then you should not trust the former either and if you do trust the former then there is no reason to not trust the latter.
    - grumbel 3y ago
      > the author of the project controls what is put in the Git repository itself The author doesn't control the Git repository. The Git repository is a shared data structure, not just bits on a server. Neither the author nor anybody else can just change the Git repository arbitrarily. They can only change it in ways allowed by Git or the alarm bells will be going off. A tarball has no such restrictions.
xorcist 3y ago
This backdoor resided in git for a year without anyone noticing. It wasn't until it was activated via the tarball that someone found out. One could easily argue that signed tarballs are more vetted than git commits.

watt 3y ago

Every commit in git repository is effectively signed by the commit hash. You can't sneak in any unreviewed changes.

badsectoracula 3y ago
But you can sneak in reviewed (by you) changes, if you have control over the repository. Again: both the Git and the tarballs are released by the same developers.
- kijin 3y ago
  You never have full control over a repository that can be cloned by others. Sure, you can rewrite the history, but anyone who has been pulling from your repo will notice the conflict. Whether you can trust the developer is beside the point. The question is how easily we can tell if someone is (still) trustworthy. Source control brings a measure of accountability into the game, making it more difficult for unusual activity to go undetected.
  - badsectoracula 3y ago
    It is not beside the point, it is the ENTIRE point. If you do not trust the developer then Git wont help you, the developer can put their malicious code in the repository itself. Git wont help you prevent anything, it is just a bunch of random files (as someone mentioned above) with the only difference being that there is a change history attached. But that wont prevent anyone with proper legitimate access (i.e. not trying to compromise it) to the repository from adding malicious code. All it may help with is figuring out, after the fact (of finding the compromise) when it was added. As i wrote above, the Git repository is not any more trustworthy than the tarballs: if you do not trust the latter then you should not trust the former either and if you do trust the former then there is no reason to not trust the latter.
    - kijin 3y ago
      > Git wont help you prevent anything Of course. Nothing does. > All it may help with is figuring out, after the fact (of finding the compromise) when it was added. Exactly. And that's what I'm trying to say. Ease of detection discourages bad behavior, just as regular police patrols help reduce crime in a neighborhood. With a public git repo, every commit increases the chance of detection long before a tarball is ready for release. I never said that I trust the git repo. I trust the eyeballs more, and the pitchforks too.

bdd8f1df777b 3y ago

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.