Date: Fri, 21 Jun 2019 17:44:33 +0100 From: Simon McVittie <smcv@...ian.org> To: oss-security@...ts.openwall.com Subject: Re: Re: Thousands of vulnerabilities, almost no CVEs: OSS-Fuzz On Fri, 21 Jun 2019 at 08:08:36 -0700, Ian Zimmerman wrote: > On 2019-06-21 10:57, Simon McVittie wrote: > > If upstream projects have a stable branch that is genuinely stable > > and bugfix-only to minimize the risk of regressions > > Doesn't this simply shift the work of backporting ("crazy and bound to > always fail in the end") from the distro maintainer to the upstream > stable branch maintainer? Yes. If we want fixes with minimal regression risk then someone has to do the work, and it might as well be someone who understands the upstream codebase and is releasing something that regression-averse redistributors can share, rather than each redistributor reinventing essentially the same backports. It isn't coincidence that the stable branches in dbus closely match what I need as a downstream maintainer, and I'd be delighted to see more downstream maintainers get involved upstream. I agree that backporting will always fail in the end, but to quote Keynes, "in the long run, we are all dead". Backporting indefinitely can't work, because eventually the backports either become infeasible, or have a greater regression risk than upgrading to the latest version; but if backports can remain feasible and lower-risk than the latest upstream development release for the support lifetime of a downstream stable release, or even for a fraction of the support lifetime of a downstream, then that finite lifetime has still provided value. Sure, some projects are so fast-moving that backports quickly become infeasible, but a lot of projects just aren't that fast (perhaps despite their maintainers' best intentions). Similarly, I'm sure there are some projects that have such good QA that the latest feature release always has a lower regression risk than backporting fixes, but I'm not sure that I could name one. A few high-profile projects like the Linux kernel are blessed with large numbers of developers, a strict review process, lots of QA and enough early-adopter users that release candidates actually get tested; but despite all that, even the Linux kernel suffers from regressions and destabilizing changes, and even the Linux kernel has backport-based stable-branches for downstreams' benefit (two tiers of stable-branches, even). For those of us who are trying to keep smaller projects afloat with resources that add up to a fraction of a full-time developer, trying to do better than the Linux kernel doesn't seem viable. 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.