Why noting security fixes in Linux kernel changelogs doesn't really help

People periodically ask for the Linux kernel commit messages and changelogs to mark changes that are security fixes, generally so that they can easily know that they need to cherry-pick just those fixes into their own kernel versions. Ignoring the higher level level issues with this for the moment, there are at least three practical difficulties:

• not all security fixes are recognized as such at the time; sometimes even the people making a change think that they are just fixing an ordinary bug, and the security implications are only recognized later.

• just because you can find a specific change that fixes a security bug doesn't mean that you can use it as-is in another kernel. This goes beyond merely the need to backport the specific change; it means that you need a deep understanding of the code so you can tell if just the change alone is sufficient, or if the fix actually implicitly relies on an earlier change that modified some behavior that is now important for this bug and fix.

  (Even having exploit code that you can test against isn't complete assurance, because it just tells you that this exploit doesn't work any more; it doesn't tell you that you have completely patched the hole.)

• it is fundamentally the wrong approach if you are maintaining a kernel code base, because it means that you are always scrambling to close vulnerabilities after they have been very publicly disclosed. What you should be doing is being proactive instead of reactive; you should be finding out about the problem and developing your own patch for your kernel version concurrently with the patch development for the main kernel.

There is one relatively sensible use for this sort of information: deciding if you need to upgrade the kernel on your production machines to the latest available version, and how urgently. But this doesn't require specific details and marked changes, just 'this kernel is known to fix security issues in the following areas' summary information.