Linked by fvillanustre on Fri 6th May 2011 22:19 UTC
Permalink for comment 472169
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Features
Linked by Thom Holwerda on 05/18/13 21:33 UTC
Linked by David Adams on 05/16/13 4:23 UTC
Linked by Thom Holwerda on 05/11/13 21:41 UTC
Linked by Thom Holwerda on 05/08/13 14:22 UTC
Linked by Thom Holwerda on 05/02/13 15:28 UTC
Linked by Thom Holwerda on 04/29/13 21:06 UTC
Linked by Thom Holwerda on 04/24/13 22:24 UTC
Linked by Thom Holwerda on 04/18/13 11:21 UTC
Linked by Thom Holwerda on 04/16/13 9:29 UTC
Linked by Thom Holwerda on 04/15/13 22:44 UTC
More Features »
Sponsored Links



Member since:
2008-02-26
Frankly, that might be the case for some projects but it is far from usual. I recommend De Raadt's speech on the release process. Compare with Xorg. Not the fixed version in your OS but the real thing.
My guess? They don't want to deal with people feeling entitled to commit their cool stuff on one hand, and students that still have many things to learn bothering them on the other.
The OpenBSD developer team is built on trust. They expect one to make many minor contributions, do boring testing, etc before being allowed to play with a new malloc.
Other projects would just review the contributed source and commit.
This attitude probably throws away perfectly good code but consider the following:
"My code is secure" - Anonymous Coward.
"My code is secure" - Someone who you know has picked up and fixed many bugs in the past.
BTW, trust is there "in addition to" code reviews, not "instead of".
ACLs, jails, package signing will be there the day someone willing to do the hard work and make them acceptable to the existing devs. In OpenBSD, "stupid" is a synonym for "No one has been willing to do it right".
The "insecurity" of the C language has been dealt with as far as they are concerned. They are more worried about higher level bugs such as juggling with permissions, trusting user input, race conditions, algorithm holes, etc. Haskell, Java or C, it doesn't matter if something is logically wrong.