Re: [tlug] Confessions of a closet OpenBSD user

["Stephen J. Turnbull" <stephen@example.com>]

>>>>> "jb" == Jonathan Q <jq@example.com> writes:

    jb> But if we step back for a wider view of the situation, we can
    jb> see that while neither SSH nor OpenSSH have perfect security
    jb> histories (what does?)  they both have very good ones.

The issue is not the record.  Of course OpenSSH's record is very good;
given the parentage of the code, much of it is simply the excellent
record of real SSH, repeated!  But that's the whole point of open
source, and the OpenSSH team deserves credit, not brickbats, for
building on a successful product where they could.

The problem is the development process.  Given the nature of the
contribution they want to claim, I think the Open* team has the
responsibility to publish in the usual fora, and to send patches
upstream.  That's just part of the job if you want to be counted a
white hat.  And as the MDs keep pointing out, from a security
standpoint there was little need for OpenSSH in a great hurry.
(Granted, it keeps down license costs for companies.)  But (according
to people I trust despite their evident anti-Theo feelings) OpenSSH
was built quickly, based on existing code with new features "bolted
on", rather than on a seamless new design.  (Not that seamless new
designs are necessarily a good thing, viz, Stallman's posture toward
ssh while the lsh project languished.)  Nor do they seem to be
particularly thorough about automating their audits (some things can't
be audited by machine, but many bounds errors can be).

When you get right down to it, the Open* team basically seems (from
the outside) to be a bunch of wannabe "heroic programmers".  Very
skilled and talented, I'm sure, but that's no way to run a railroad.
Open source has got to get away from "code and fix" if it wants to be
taken seriously in the long term.

One of the things that has impressed me about the best of the core
programmers at XEmacs is that, like everybody else, they often
introduce a sheaf of bugs along with the improvements in a big patch.
But then the resulting fixes _often make the code simpler_!  Ie, the
design was consistent and robust, they just failed to extend the
implementation far enough.  The original patch rarely needs amendment;
it's the surrounding cruft that gets pruned (sometimes allowing
simplification of the main routines).

However, besides the (unsurprising) fact that unfortunately, only
about 25% of the code is produced to that standard, what's really sad
is that we have no mechanism to encourage (let alone "force") most
contributions to come close to that standard.  It's hard to keep junk
code out.  The bugs have to be fixed, and typically the patches come
from users whose criterion is that it work for them, or developers who
would really rather be working on something else.  For the same
reason, review tends to be partial and incomplete.

It really doesn't sound to me like the OpenBSD process is enough better,
given their professed commitment to "quality" and "security."

    jb> At the end of the day, I'm left counting my blessings that
    jb> our platform has as few security vulnerabilities as it does.
    jb> Microsoft products seem to have more trouble in a month or
    jb> two than we have in a year.  Don't worry, be happy :-)

I certainly agree with that!  The _results_ have been excellent so far.

My point is just that (1) as developers we need to aspire to standards
higher than "talented amateur," and (2) as users and admins we need to
_demand_ higher standards from the development _process_, if we want
open source to continue to grow healthily, both in the market and
overall.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
 My nostalgia for Icon makes me forget about any of the bad things.  I don't
have much nostalgia for Perl, so its faults I remember.  Scott Gilbert c.l.py