David LeBlanc wrote:
First, what you want is not just people, but people who understand
both security AND the code
yes yes yes yes yes yes.
In the long term, it's extremely important to make
sure that EVERY developer is trained in how to develop
secure software. Get that info in the undergrad
programs... and the high schools.
Better tools (that didn't have as many sharp edges), etc.,
will help too, but no tool can do it all. We need to make
sure all software developers understand how to
develop secure software. It's no longer a
specialty skill; it's a required skill, and much more
important than knowing how quicksort works.
[I have a master's in Computer Science, so I know darn
well how quicksort works. But most programmers just
need to know how to call it, not how it works.
They DO need to know how to filter untrusted input.. and why.
I've never had to rewrite quicksort... why would I?
That'd be stupid; I'll just reuse a library!]
BIND and Sendmail have always been
OSS, and they've both got really bad records. We run the internet on
these, and if anything should be thoroughly vetted, it should be
these.
Instead of vetting, you're sometimes better off replacing.
I generally recommend that Sendmail users switch to
Postfix; it's almost always an easy switch for such users,
and Postfix was designed to be secure.
It's my understanding that Sendmail X is essentially a
complete re-implementation of Sendmail.
There are other apps that are OSS which have excellent
records.
Right. In other words, just being OSS -- or being proprietary --
is no guarantee of security. Thankfully, I think most
people are understanding that today.
If security is important to you (as a customer),
then you need to judge your options based
on how secure the products are...!
Michael Silke said:
> Deadlines maybe, but what is the reprocussion if they aren't met ?
> Nothing. You're not getting paid, so you don't lose many. ...
I think you're using old information.
Yes, there are many unpaid OSS projects,
but many of the projects that people talk about the most
are primarily written by people PAID to write them.
Some may have started as unpaid, but in many ways that action
looks like a small business start-up... you start making
no money, and if it's a successful project, suddenly
you're getting financial offers.
Indeed, the underappreciated story today
is the increasing commercialization of OSS.
This was always true of Apache and X-Windows, which
were and are primarily corporate consortiums.
It's certainly true of the Linux kernel;
in July 2004 Andrew Morton reported that 37,000
of the last 38,000 patches to the Linux kernel were
from people who he knew had been paid to write them.
[http://gcn.com/vol1_no1/daily-updates/26641-1.html]
For more info on this rising OSS commercialization:
http://clustering.foundries.sourceforge.net/article.pl?sid=02/08/19/1426245
http://www.freeos.com/articles/4087
http://www.dwheeler.com/oss_fs_why.html#starving-programmers
> Deadlines only matter if they actually need to be met, and in OSS
> (i.e. free, "when you have time" development) I can't think of any
> time where one would be required.
Yes, deadlines only matter if they need to met.
And that's typically where the commercial world enters in.
Deadlines for needed functionality CAUSE companies
to fund improvements to OSS projects.
Does the deadline for function X matter to you?
Great -- hire someone to implement function X
(your own people, someone in the OSS project, or a 3rd
party). If you pay them, you can then negotiate
the requirements and deadlines, as well as what happens
if a deadline or functionality isn't met.
(See http://www.msnbc.msn.com/id/5907194/ for an example).
Typically you want to avoid maintenance costs, so you
need to make sure the change will get into the official project...
which means you need to talk with the project from the beginning,
and stay engaged with them during that development.
Take a look at any OSS project mailing list, and you can
see this process in action.
Oh, you don't want to fund the OSS work (either in dollars
or in your time to implement it)? Well, you can certainly
make the request to the project. That often works well
for bug reports, since the other users don't want the bug
either, and in fact bug reports can be really valuable
(because the information you provide may be the "missing
piece" of information that helps them).
But new functionality is more dicey.
Guess what? If you're not willing to fund the OSS work
(in $ or time), maybe it's not that important to you.
This is really no different than proprietary software
purchases. If you're not willing to pay for the
proprietary software licenses, maybe that software is
not worth it to you (and I reject making illegal copies).
The OSS business model is different; you
generally don't pay for per-use licenses, you pay for
support and for extra functionality. Since these
are also where the costs are incurred (copying bits
is essentially a free operation today), this actually
makes some sense.
Of course, there's the other side; I've seen deadlines
cause many security problems ("we'll review that later").
Most of the larger OSS projects do code reviews, and
will reject code that doesn't appear to be fully baked.
Sometimes, though we don't like it, it _IS_ better
to miss a deadline. If that functionality wasn't
implemented by some deadline (or its security could not
be validated) because not enough resources
were paid to develop it... then perhaps it wasn't
that important!
One useful approach is to create deadlines
for releases, and dropping whatever isn't ready so
you meet the deadline. That way, you get forward progress,
but don't ship stuff that's not ready.
GNOME always meets its deadlines...
shedding whatever functionality it needs to meet them.
That isn't a crisis; whatever was shed is just not
ready (and thus you don't really want it), and it'll
probably be ready in the next cycle.
In the proprietary world, Microsoft has
done this often (announcing sometime later that certain
features they said they'd deliver won't be ready).
Some people seem to like bashing Microsoft about that,
but frankly I think that's a very reasonable approach --
if it's not ready, don't ship it. I guess you could
critique Microsoft for failing to fulfill a promise,
since there's no way most people could
influence Microsoft's prioritization or approach
(the approach influences the risk of failing to
meet the deadline). But to my knowledge,
Microsoft generally _does_ try to implement what it
says it plans to implement; it's not a lack of resources
or a lack of will, as far as I can tell.
Thus I think that this critique of MS isn't fair.
Sure, you should work hard to keep your promises, but
if try as hard as you can and you fail to do so,
the right thing to do is to announce
that info as soon as you can (so that others can adjust).
Sounds like what I learned in kindergarten.
And that critique makes absolutely NO sense against an
OSS project, because in an OSS project you CAN influence
the work by doing/funding it yourself, and you also
can see what the progress is if it's important to you.
Narrowing this to the security world, this is all
true for security review too. Sometimes, you've developed
something, and security issues you hadn't anticipated
begin to hit you. Perhaps there was an unanticipated
threat, or environmental change, that gravely harms
your basic design. Again, we don't like it, but
sometimes it's better to slip deadlines than create
disaster. I can point to several product releases where
I really wish they HADN'T met their deadlines :-).
--- David A. Wheeler
