4 ms·

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

by watt 3y ago

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.
      - badsectoracula 3y ago
        Ease of detection is not a thing here since nothing is detected. The only thing you can have with Git is figuring out when a change was made after it has been detected - by different means. And again, when someone can submit to a repository as developer and also make tarball releases, it makes no sense to differentiate between the two if you are worrying about malicious code. Your original comment was why "maintainers of major distros still rely on questionable tarballs to build packages" instead of Git. And IMO the answer is really simple: because if they trust a project's developers to not put malicious code in their project, it makes no difference if the code came from Git or an explicitly provided release tarball. If such trust wasn't there, chances are the project wouldn't be part of a distribution in the first place.
  - giantrobot 3y ago
    > but anyone who has been pulling from your repo will notice the conflict. Not will but can notice a conflict. Repos edit history all the time for a variety of reasons. Well written but nefarious changes to history won't immediately be recognized as nefarious. Besides once there's multiple copies of a repo available with different histories, who is to say which is the canonical repo for a project?
Khaine 3y ago
Yes, and that didn't save us from the xz backdoor did it?

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

by watt 3y ago

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

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.
    - badsectoracula 3y ago
      Ease of detection is not a thing here since nothing is detected. The only thing you can have with Git is figuring out when a change was made after it has been detected - by different means. And again, when someone can submit to a repository as developer and also make tarball releases, it makes no sense to differentiate between the two if you are worrying about malicious code. Your original comment was why "maintainers of major distros still rely on questionable tarballs to build packages" instead of Git. And IMO the answer is really simple: because if they trust a project's developers to not put malicious code in their project, it makes no difference if the code came from Git or an explicitly provided release tarball. If such trust wasn't there, chances are the project wouldn't be part of a distribution in the first place.
- giantrobot 3y ago
  > but anyone who has been pulling from your repo will notice the conflict. Not will but can notice a conflict. Repos edit history all the time for a variety of reasons. Well written but nefarious changes to history won't immediately be recognized as nefarious. Besides once there's multiple copies of a repo available with different histories, who is to say which is the canonical repo for a project?

Khaine 3y ago

Yes, and that didn't save us from the xz backdoor did it?