Jose de Paula Eufrasio Junior wrote:
> Hello, before anything else, I did read all material about the OpenBSD
> security policies on the website. Now I am trying to get some more
> insider insight on it.
> Writing a paper about open source software security and not including
> OpenBSD case is kinda idiot so I am running against time to find more
> info.
>
> I made a simple list of 5 questions to be answered by an active
> developer of the project, the questions are below. If you feel you
> have a little time to help me on that, please reply to my private
> email to prevent unecessary trafic. I used the same questions on all
> projects I researched so they are not specific questions.
(I'm not a coder on the OpenBSD project, and with pretty good
reason. So take this with a Michigan Salt Truck of salt...)
I've seen lots of attempts to "script" various processes into
simple formulas, where people can say, "Do this and you get
quality/security/economy/whatever". Usually, they are sold by
consultants and snake-oil sales people, and bought by managers
who are otherwise having difficulty justifying their existence
in a company (and sometimes in life itself), who sometimes
think they can replace their quality people with commodity
employees if they just follow The Script.
I think the OpenBSD security process could be summed up as:
1) Security is just a side-effect of quality.
2) Quality comes from not screwing up
3) If you screw up, don't be so egotistical as to assume the
screwup was unique, and look for the other occurrences.
4) If you see someone else screw up, assume they aren't
any more original than you are, and go find the other
occurrences, too.
5) If you are sick and tired of the completely thankless
task of looking for problems before they become problems,
you might be doing it right.
The really short version, though, is:
"Don't screw up".
It all boils down to that. Well, not really, internally we
use a lot stronger language than that. But that gets the
point across in a family-friendly sort of way. :)
Rules #3 and #4 are just two of the many ways to not screw
up, and #5 is mostly a cynical side-effect.
I can name lots of little "rules" I've seen practiced, but
most likely, you or someone would say, "Ah, that's the secret!"
and formalize it into a rigid set of rules that will not
improve quality of ANYTHING, but will get smart people pissed
off and they'll follow your rules (to their amusement) and the
dumb people (the vast majority) will think they are doing it
RIGHT because they are following The Rules.
Skilled people who care will always be looking for new ways
things can go wrong, even if they aren't on the script.
Dumb managers will happily spend lots of money to have their
operations certified as doing it by the script rather than
spending a lot less to really do it right.
"Don't screw up", though, gets the point across effectively.
If you see a problem that could happen, you have been told
to fix it. If you let it happen, you violated the rule. If
you didn't see it, you violated the rule. If you fix a
problem that no one was aware of and no one thanks you for
it, you are doing it right.
Problem is, you can't say "Don't screw up" and then hit a
company with a $100,000 fee, as they will usually start to
think they did... I also doubt you can write your
dissertation with just three words on it, even if it is what
it all really boils down to.
Nick.
