4 ms·

Everything we do in life relies on a trust system more or less. Reproducible build only guarantees integrity, not the trustworthiness of the code. > There is n

Everything we do in life relies on a trust system more or less. Reproducible build only guarantees integrity, not the trustworthiness of the code. > There is no way for anyone to know what all this code is doing, there is little way to verify updates and its simply untenable. Because few people have time to read source code. Take Django as an example. Big community, lots of contributors. Can we say we should trust the code because the number of eyes? Probably, but not always. Why? We can overlook and pretend the code is legitmate. Take Linux kernel or some of the crypto projects out there. A lot of unreadable old tricks made backdoor really easy. [1] is interesting because someone apparently made an authorized changeset to BitKeeper. Are you going to read JRE code to make sure no backdoor? Nah. Is there a solution? Nope and will never have a solution. The best one can do is using a DVCS to prevent unathorized changeset (provided every contributor does a sanity check for pulling in changeset) and trust the community. No machine can distinugish a good code from a bad code. Humans can't even tell unless raising a red flag. Sometimes change of project ownership can also introduce some uncertainty, but that is a rare case for major projects. I am pretty confident there are code in the Linux kernel no one has ever touched or ever read for years. [1]: https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-attempt-of-2003/ https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-...

rlpb 9y ago
Distributions - let's take Debian as a concrete example - provide an audit trail to individual identified developers as a mitigation for users relying on trust. Just because we must necessarily rely on some level of trust does not mean that we must blindly trust, which is what happens when anyone can upload to a repository such as PyPI.
- deleted 9y ago
  [deleted]
- yeukhon 9y ago
  As far as I know, once the project name is taken, that ownership belongs to the account first created this package in PyPI.
zero_one_one 9y ago
Not only reading source code - how many people disassemble their compiled code and check for any unwanted side effects the compiler may have generated? For any non-trivial code base, this is not an option, hence where the implicit trust in the tools lies, and also the potential for exploitation
zizek23 9y ago
Only the developers know why they need 150 deps, there is no way for end users or deployment to verify this chain or stay on top of this. They simply need to deploy the app and keep it updated safely. If developers and languages have not thought of this basic step then please defer to the distribution package manager which has. These kind of frauds won't pass the average distribution package managers scrutiny and CVEs will have quick updates that are tested to work. Contrast this with users scrambling to update affected apps and their individual local libraries which in turn may have their own specific deps which may not have been updated and thus will fail because of version inconsistencies. End result. Millions of man hours wasted because of clearly bad engineering practices.
xorcist 9y ago
> someone apparently made an authorized changeset to BitKeeper I suggest you read the link you mentioned. It was not an authorized change in BK, it was not an authorized change at all. It was only in a third-party CVS mirror, and it was found exactly when someone asked why there was a changeset in the CVS mirror that wasn't in BK. And while I don't doubt that there are enough unreadable code to hide a backdoor in, certainly anywhere in the massive driver tree, this backdoor is a fairly obvious one. I don't think you could hide an assignment as a comparison through code review. It's such a common error to make that it really stands out. > Are you going to read JRE code to make sure no backdoor? That is a highly misleading question. While I will trust the JRE developers without checking every single change, they are a diverse bunch enough that the fact that they are checking each other's work goes a long way. It's very much the same situation as with the kernel and the compiler. The difference is only one of magnitude. The difference between that and nodejs or ruby where any one can upload anything, anonymously and completely unchecked, is enormous.
- yeukhon 9y ago
  I was intended to say unauthorized change but spell check fucked me up, although you could probably tell my actual intention from the rest of my comment. Thanks for pointing out. I ack when it comes to size my comparison is not fair, but I am trying to say just because there is a large community, we sometimes still overlook. Usually big projects would have some "module owners" to approve merge. This limits to a number of people. If the project is active enough, there will be dozens of commits or more per day. Sometimes people really do overlook and let things pass. Until someone spots something wrong, the code could have been in the wild for days or years.
Nursie 9y ago
These problems you bring up are a different order to the "grab stuff from wherever" culture that seems to have sprung up around a lot of languages lately.

rlpb 9y ago

Distributions - let's take Debian as a concrete example - provide an audit trail to individual identified developers as a mitigation for users relying on trust. Just because we must necessarily rely on some level of trust does not mean that we must blindly trust, which is what happens when anyone can upload to a repository such as PyPI.

deleted 9y ago
[deleted]
yeukhon 9y ago
As far as I know, once the project name is taken, that ownership belongs to the account first created this package in PyPI.

zero_one_one 9y ago

Not only reading source code - how many people disassemble their compiled code and check for any unwanted side effects the compiler may have generated? For any non-trivial code base, this is not an option, hence where the implicit trust in the tools lies, and also the potential for exploitation

zizek23 9y ago

Only the developers know why they need 150 deps, there is no way for end users or deployment to verify this chain or stay on top of this. They simply need to deploy the app and keep it updated safely. If developers and languages have not thought of this basic step then please defer to the distribution package manager which has. These kind of frauds won't pass the average distribution package managers scrutiny and CVEs will have quick updates that are tested to work. Contrast this with users scrambling to update affected apps and their individual local libraries which in turn may have their own specific deps which may not have been updated and thus will fail because of version inconsistencies. End result. Millions of man hours wasted because of clearly bad engineering practices.

xorcist 9y ago

> someone apparently made an authorized changeset to BitKeeper I suggest you read the link you mentioned. It was not an authorized change in BK, it was not an authorized change at all. It was only in a third-party CVS mirror, and it was found exactly when someone asked why there was a changeset in the CVS mirror that wasn't in BK. And while I don't doubt that there are enough unreadable code to hide a backdoor in, certainly anywhere in the massive driver tree, this backdoor is a fairly obvious one. I don't think you could hide an assignment as a comparison through code review. It's such a common error to make that it really stands out. > Are you going to read JRE code to make sure no backdoor? That is a highly misleading question. While I will trust the JRE developers without checking every single change, they are a diverse bunch enough that the fact that they are checking each other's work goes a long way. It's very much the same situation as with the kernel and the compiler. The difference is only one of magnitude. The difference between that and nodejs or ruby where any one can upload anything, anonymously and completely unchecked, is enormous.

yeukhon 9y ago
I was intended to say unauthorized change but spell check fucked me up, although you could probably tell my actual intention from the rest of my comment. Thanks for pointing out. I ack when it comes to size my comparison is not fair, but I am trying to say just because there is a large community, we sometimes still overlook. Usually big projects would have some "module owners" to approve merge. This limits to a number of people. If the project is active enough, there will be dozens of commits or more per day. Sometimes people really do overlook and let things pass. Until someone spots something wrong, the code could have been in the wild for days or years.

Nursie 9y ago

These problems you bring up are a different order to the "grab stuff from wherever" culture that seems to have sprung up around a lot of languages lately.