3 ms·

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

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.

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.