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.