Re: Re: Thousands of vulnerabilities, almost no CVEs: OSS-Fuzz

[Simon McVittie <smcv () debian org>]

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