> 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.
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.
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.