[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190621095616.GA5186@espresso.pseudorandom.co.uk>
Date: Fri, 21 Jun 2019 10:57:45 +0100
From: Simon McVittie <smcv@...ian.org>
To: oss-security@...ts.openwall.com
Subject: Re: Thousands of vulnerabilities, almost no CVEs:
OSS-Fuzz
On Fri, 21 Jun 2019 at 11:32:05 +0200, Yves-Alexis Perez wrote:
> I sympathize with this view, and I think we need to get better at updating,
> but I really think not all projects can be “safely” just updated to the latest
> version.
If upstream projects have a stable branch that is genuinely stable
and bugfix-only to minimize the risk of regressions, and encourage
downstream distributions to align on the latest stable branch during
their development phase, then I think that goes a long way towards this.
If I understand correctly, PostgreSQL is one of the canonical examples of
a project that does this, and gets its upstream point releases included
in stability-focused projects like Debian as-is.
I have tried to manage dbus like this, with all new APIs and new features
appearing only in the development branch, and the result is that the
Debian release and security teams have generally been willing to take
upstream stable releases within the same branch branch.
Of course, for this to work, the upstream project needs to build a
reputation for not introducing regressions or unnecessary changes in
stable branches, so that downstream distributors can trust them (which
will take a while if the upstream has a previous history of regressions,
unnecessary changes or poorly-labelled changes).
> And before reaching the end-user, some project latest versions might depend on
> a lot of “latest version” of other projects.
Yes, that's certainly a potential problem, and new non-optional
dependencies on a stable branch should usually be treated as a regression.
It's probably fine for a stable branch to have a new *optional*
dependency, like dbus >= 1.10.24 checking for Expat >= 2.1.0 and using
XML_SetHashSalt() if available - although even that can become a problem
if a binary distribution doesn't have symbol-level dependency tracking
like Debian does.
smcv
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.
