In a comment on my entry on how the current Linux kernel CVE policy is sort of predictable, Ian Z aka nobrowser asked what a distribution like Debian is supposed to do today, now that the kernel developers are not going to be providing security analysis of fixes, especially for unsupported kernels (this is a concise way of describing the new kernel CVE policy). I don't particularly have answers, but I have some thoughts.

The options I can see today are:

• More or less carrying on with a distribution specific kernel and backporting fixes into it if they seem important enough or otherwise are security relevant. This involves accepting that there will be some number of security issues in your kernel that are not in the upstream kernel, but this is already the case in reality today (cf).

• Synchronize distribution releases to when the upstream kernel developers put out a LTS kernel version that will be supported for long enough, and then keep updating (LTS) kernel patch levels as new ones are released. Unfortunately the lifetime of LTS kernels is a little bit uncertain.

  My guess is that this will still leave distributions with any number of kernel security issues, because only bugfixes recognized as important are applied to LTS kernels. The Linux kernel developers are historically not great at recognizing when a bugfix has a security impact (cf again). However, once a security issue is recognized in your (LTS) kernel, at least the upstream LTS team are the ones who'll be fixing it, not you.

• Give up on the idea of sticking with a single kernel version (much less a single patch level within that version) for the lifetime of a distribution release. Instead, expect to more or less track the currently supported kernels, or at least the LTS kernels (which would let you do releases whenever you want).

  (This is what Fedora currently does with the mainline kernel, although a distribution like Debian might want to be less aggressive about tracking the latest kernel version and patchlevel.)

Broadly, distributions are going to have to decide what is important to them. Just as we say 'good, cheap, fast, pick at most two', distributions are not going to be able to release whenever they want, use a single kernel version for years and years, and get perfect security in that kernel. Or at least they are not going to get that without doing a lot of work themselves.

(Again, the reality is that distributions didn't have this before; any old distribution kernel probably had a number of unrecognized security issues that had already been fixed upstream. That's kind of what it means for the average kernel CVE fix time between 2006 and 2018 to be '-100 days' and for 41% of kernel CVEs to have already been fixed when the CVE was issued.)

A volunteer-based distribution that prioritizes security almost certainly has no option other than closely tracking mainline kernels, and accepting whatever stability churn ensues (probably it's wise to turn off most or all configurable new features, freezing on the feature set of your initially released kernel). Commercial distributions like Red Hat Enterprise and Canonical Ubuntu can do whatever their companies are willing to pay for, but in general I don't think we're going to keep getting long term support for free.

(A volunteer based distribution that prioritizes not changing anything will have to accept that there are going to be security issues in their kernels and they will periodically scramble to find fixes or create fixes for them, and maybe get their own CVEs issued (and possibly have people write sad articles about how this distribution is using ancient kernels with security issues). I don't think this is a wise or attractive thing myself; I would rather keep up with kernel updates, at least LTS ones.)

Distributions don't have to jump on new kernel patchlevels (LTS or otherwise) or kernel versions immediately when they're released; not even Fedora does that. It's perfectly reasonable to do as much build farm testing as you can before rolling out a new LTS patch release or whatever, assuming that there are no obvious security issues that force a fast release.