[drysart]

> However you look at it, the only real justification that’s consistent with observed behaviors is that pointing out security vulnerabilities in the development log helps attackers.

And on top of your other concerns, this quoted bit smells an awful lot like 'security through obscurity' to me.

The people we really need to worry about today, state actors, have plenty of manpower available to watch every commit going into the kernel and figure out which ones are correcting an exploitable flaw, and how; and they also have the resources to move quickly to take advantage of them before downstream distros finish their testing and integration of upstream changes into their kernels, and before responsible organizations finish their regression testing and let the kernel updates into their deployments -- especially given that the distro maintainers and sysadmins aren't going to be moving with any urgency to get a kernel containing a security-critical fix rolled out quickly because they don't know they need to because *nobody's warned them*.

Obscuring how fixes are impactful to security isn't a step to avoid helping the bad guys, because they don't need the help. Being loud and clear about them is to help the good guys; to allow them to fast-track (or even skip) testing and deploying fixes or to take more immediate mitigations like disabling vulnerable features pending tested fix rollouts.

[suspended_state]

There are channels in place to discuss security matters in open source. I am by no mean an expert nor very interested in that topic, but just searching a bit led me to

https://oss-security.openwall.org/wiki/mailing-lists

The good guys are certainly monitoring these channels already.

[vlovich123]

There’s lot of different kinds of bad guys. This probably has marginal impact on state actors. But organized crime or malicious individuals? Probably raises the bar a little bit and part of defense in depth is employing a collection of mitigations to increase the cost of creating an exploit.