OpenSSL cannot share with OpenBSD team because the OpenBSD team would not think twice about committing those fixes, making those issues public.
[A founding value of OpenBSD is about making anonymous access to their code repository: they develop the same tree that we see. Believe it or not, this was a radical stance for its time.
This is contrary to NetBSD's policy at the time of the fork: their code was only published at time of release, making contributions very difficult for outsiders, and withholding security fixes. Theo suspected people with commit access developed attacks based on these changes prior to next release.]
I can't recall any time where OpenSSH security fixes were withheld. Although OpenBSD developers do not take the time to evaluate whether a bug may always be exploitable, they do not hesitate to announce the possibility. http://www.openbsd.org/errata.html
This is contrary to the approach by Linus on the linux kernel, where security issues "are just normal bugs", placing the responsibility of downstream vendors (and attackers) to evaluate whether they are also a security issue, https://lkml.org/lkml/2008/7/15/648
I do not remember Theo ever telling me in the 1990s that he believed NetBSD team members were using their access to develop attacks. His opinion of the NetBSD team was far too low to give them that much credit. Theo was much more likely to believe that the concepts behind attacks were invented in the OpenBSD tree, and if he had a problem with how NetBSD managed its tree, it was that they wouldn't track OpenBSD fixes.
I don't know what Theo's saying these days. It's been over a decade since I talked to him. But I talked to him a lot in the earlier days of the project, during the original audit, during which time I wrote the OpenBSD advisories, sometimes at the Ship & Anchor in Calgary with him. I would remember this accusation. I never heard it.
Not really. I had commit privileges (a year earlier I had them briefly on FreeBSD, because of the crt0.c bug) but I used them I think twice, once to do something to ping(8) and once to add RADIUS support to tcpdump. I did however write many of the OpenBSD security advisories, and participated in the audit. In 1997, when I moved to Calgary for a few months to work for Secure Networks, Theo was the first person I met there.
To this day I still don't know how to use icb, which if you're an OpenBSD person tells you how much a part of that team I was.
I'm not smart or anything. I'm just (I assume) older than you are. And I got a very early start. That FreeBSD thing happened the year after I graduated high school. I skipped college and went right into dev.
That's not true. We will withhold disclosure for a reasonable amount of time. 3 days is certainly reasonable.
For locally "sourced" errata, we do handle disclosure a little differently. A fix gets committed. Then a patch gets made. Then an email gets sent. That's about it. What we don't have is a secret cvs branch where we bundle up six or more vulns for disclosure all at once while our premium platinum access partners yank our chain.
OpenBSD developers fix a lot of bugs in the course of development, the far reaching security consequences of seemingly innocuous pieces of code are often difficult to evaluate, instead fixes go in and the tree swept for further occurrences. Hardly radical, I'd even say normal.
Comments
OpenSSL cannot share with OpenBSD team because the OpenBSD team would not think twice about committing those fixes, making those issues public.
[A founding value of OpenBSD is about making anonymous access to their code repository: they develop the same tree that we see. Believe it or not, this was a radical stance for its time.
This is contrary to NetBSD's policy at the time of the fork: their code was only published at time of release, making contributions very difficult for outsiders, and withholding security fixes. Theo suspected people with commit access developed attacks based on these changes prior to next release.]
I can't recall any time where OpenSSH security fixes were withheld. Although OpenBSD developers do not take the time to evaluate whether a bug may always be exploitable, they do not hesitate to announce the possibility. http://www.openbsd.org/errata.html
This is contrary to the approach by Linus on the linux kernel, where security issues "are just normal bugs", placing the responsibility of downstream vendors (and attackers) to evaluate whether they are also a security issue, https://lkml.org/lkml/2008/7/15/648
I do not remember Theo ever telling me in the 1990s that he believed NetBSD team members were using their access to develop attacks. His opinion of the NetBSD team was far too low to give them that much credit. Theo was much more likely to believe that the concepts behind attacks were invented in the OpenBSD tree, and if he had a problem with how NetBSD managed its tree, it was that they wouldn't track OpenBSD fixes.
I don't know what Theo's saying these days. It's been over a decade since I talked to him. But I talked to him a lot in the earlier days of the project, during the original audit, during which time I wrote the OpenBSD advisories, sometimes at the Ship & Anchor in Calgary with him. I would remember this accusation. I never heard it.
Every time I read one of your comments, it is a fascinating look into cryptography. Now you're telling me you were part of the OpenBSD team?
I guess I need to search through your past comments, and a quick Google indicates I missed this.
Every time you comment here you make me feel so lazy. Haha.
Not really. I had commit privileges (a year earlier I had them briefly on FreeBSD, because of the crt0.c bug) but I used them I think twice, once to do something to ping(8) and once to add RADIUS support to tcpdump. I did however write many of the OpenBSD security advisories, and participated in the audit. In 1997, when I moved to Calgary for a few months to work for Secure Networks, Theo was the first person I met there.
To this day I still don't know how to use icb, which if you're an OpenBSD person tells you how much a part of that team I was.
I'm not smart or anything. I'm just (I assume) older than you are. And I got a very early start. That FreeBSD thing happened the year after I graduated high school. I skipped college and went right into dev.
That's not true. We will withhold disclosure for a reasonable amount of time. 3 days is certainly reasonable.
For locally "sourced" errata, we do handle disclosure a little differently. A fix gets committed. Then a patch gets made. Then an email gets sent. That's about it. What we don't have is a secret cvs branch where we bundle up six or more vulns for disclosure all at once while our premium platinum access partners yank our chain.
Ha, I was close on my estimate.
What isn't a "normal bug"?
OpenBSD developers fix a lot of bugs in the course of development, the far reaching security consequences of seemingly innocuous pieces of code are often difficult to evaluate, instead fixes go in and the tree swept for further occurrences. Hardly radical, I'd even say normal.
"OpenSSL cannot share with OpenBSD team because the OpenBSD team would not think twice about committing those fixes, making those issues public."
Really? That is not the read I get off the Mailing list. I would like to see the e-mail where they say that.