4 ms·

> Maybe the silver lining here is that it puts the final nail in the coffin for "many eyes make all bugs shallow" The OpenSSL project doesn't seem to have a 'r

by nikcub 13y ago

> Maybe the silver lining here is that it puts the final nail in the coffin for "many eyes make all bugs shallow" The OpenSSL project doesn't seem to have a 'review' step[0] in code commits, unlike FreeBSD, OpenBSD and Chromium (i'm just picking projects i'm familiar with, no bias). So it might not have been 'many eyes', but the eyes of just one. edit: [0] a proper review step, what the openssl project does is have feedback on commits (which is what the OP article is referring to). see below.

sp332 13y ago
The article says there was a reviewer who looked at this code before it was moved to the release branch.
- nikcub 13y ago
  It refers to 'review' as in reviewing the features and how it is implemented. Here is the log: http://rt.openssl.org/Ticket/Display.html?id=2658&user=guest&pass=guest http://rt.openssl.org/Ticket/Display.html?id=2658&user=guest... That is very far from it being a security review, or any real proper review. It is more a request for comments (which defaults to code being committed) You'll notice that the workflow for commits doesn't have a review stage, and it isn't implemented in the workflow software. Compare to a chromium example, where each commit, eg. http://src.chromium.org/viewvc/chrome?view=revision&revision=262978 http://src.chromium.org/viewvc/chrome?view=revision&revision... has a review stage that the original committer doesn't have permissions for. In this case 3 reviewers for that commit: https://codereview.chromium.org/231923002 https://codereview.chromium.org/231923002 Code doesn't get committed without at least 4 people, its like a 2-man rule that is enforced in the workflow. In contrast the openssl process is that the same committer can push the code after getting no objections. There is a big difference in how each of these processes work.
notacoward 13y ago
The "many eyes" canard isn't just about formal reviews, though. It's also about the idea that when something's open source the reviews aren't limited to maintainers or close colleagues who would be involved regardless of open vs. proprietary. What actually seems to happen in the great majority of cases is that the circle of people who actually understand any particular commit is only very slightly greater than it would be otherwise. The bugs are only a very tiny bit shallower, if at all. The fact that it was just one reviewer in this case, despite the code being widely available, only underscores that point.

by nikcub 13y ago

sp332 13y ago

The article says there was a reviewer who looked at this code before it was moved to the release branch.

nikcub 13y ago
It refers to 'review' as in reviewing the features and how it is implemented. Here is the log: http://rt.openssl.org/Ticket/Display.html?id=2658&user=guest&pass=guest http://rt.openssl.org/Ticket/Display.html?id=2658&user=guest... That is very far from it being a security review, or any real proper review. It is more a request for comments (which defaults to code being committed) You'll notice that the workflow for commits doesn't have a review stage, and it isn't implemented in the workflow software. Compare to a chromium example, where each commit, eg. http://src.chromium.org/viewvc/chrome?view=revision&revision=262978 http://src.chromium.org/viewvc/chrome?view=revision&revision... has a review stage that the original committer doesn't have permissions for. In this case 3 reviewers for that commit: https://codereview.chromium.org/231923002 https://codereview.chromium.org/231923002 Code doesn't get committed without at least 4 people, its like a 2-man rule that is enforced in the workflow. In contrast the openssl process is that the same committer can push the code after getting no objections. There is a big difference in how each of these processes work.

notacoward 13y ago

The "many eyes" canard isn't just about formal reviews, though. It's also about the idea that when something's open source the reviews aren't limited to maintainers or close colleagues who would be involved regardless of open vs. proprietary. What actually seems to happen in the great majority of cases is that the circle of people who actually understand any particular commit is only very slightly greater than it would be otherwise. The bugs are only a very tiny bit shallower, if at all. The fact that it was just one reviewer in this case, despite the code being widely available, only underscores that point.