[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 15 Jun 2019 14:57:19 -0700
From: Alan Coopersmith <alan.coopersmith@...cle.com>
To: oss-security@...ts.openwall.com,
"David A. Wheeler"
<dwheeler@...eeler.com>
Subject: Re: Thousands of vulnerabilities, almost no CVEs:
OSS-Fuzz
As one of the maintainers of a pile of packages included in pretty much every
Linux distro (the X.Org libraries, clients, servers, & drivers), which has had
a fair number of CVE's, I would love to do all of these - and we do what we can
now (mostly 1 & 3). We're not ignoring the rest - we just don't have enough
contributors to do all that, and I know we're far from the only FOSS project
with this problem.
This is a lot of work, and when the people making money off the software aren't
using that money to pay for this work, they can't be surprised when it doesn't
get done.
-Alan Coopersmith- alan.coopersmith@...cle.com
X.Org Security Response Team - xorg-security@...ts.x.org
On 6/15/19 1:54 PM, David A. Wheeler wrote:
> I think that's fair, but I think projects have their part to play too:
>
> 1. Projects should work much harder at avoiding backwards-incompatible changes.
> Some projects (though *not* the Linux kernel) seem to take a very
> cavalier attitude to breaking changes. Yes, change is sometimes necessary,
> but projects need to work harder at providing graceful upgrades.
> (Slow deprecations, providing altenative differently-named 'new' interfaces
> with different semantics that let people gradually transition, and so on).
> IN PARTICULAR: I believe the primary reason that distros
> often backport, instead of using the "current" version, is because their
> users correctly fear backwards-incompatible changes. If projects would stop
> being the problem, then distros wouldn't feel the need to solve the problem.
> 2. Everyone needs test suites to detect problems from changes & upgrades.
> Since everyone is making changes, including upgrading components,
> everyone should have test suites to detect problems before they ship.
> Then upgrading will be much easier and less likely to cause problems.
> 3. Projects should be using static analysis tools to detect problems
> ahead-of-time. Yes, they have false positives and false negatives.
> Be kind to your users, and use tools to help find & fix the bugs
> instead of inflicting them on your users.
> 4. Input validation, input validation, input validation.
> If projects' software would be pickier about what they accept,
> many vulnerabilities and bugs wouldn't have a chance.
> 5. Apply other good security techniques, like hardening against
> the inevitable problems.
> 6. I'd like to see more projects fuzzing themselves before they ship.
> I'm probably dreaming on this point, but I can dream :-).
> These won't solve everything, but it will reduce the trauma.
>
> Many of these points are covered by the CII Best Practices badge.
> I encourage OSS projects to work to get a badge:
> https://bestpractices.coreinfrastructure.org/
> (Full disclosure: I lead that project. But I hope it's useful anyway :-) .)
>
> I'm not revealing any grand new ideas. They're kind of basic.
> However, they seem to be ignored by too many projects today.
> I think if more projects would "do unto others as you
> would have them do unto you", then handling
> this stuff would be a lot less painful :-).
>
> --- David A. Wheeler
>
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
