that's a false dichotomy, not to mention a confusion of cause and effect. in particular, what we've been asking for is honesty. being honest implies that 1. if i submit a commit with a description containing, say, 'this is a fix for a buffer overflow' then i do *not* want them to remove 'buffer overflow' from there (i.e., they're expected to 'change what they accept', censorship at this level is simply ridiculous), 2. if i submit a bugreport with a PoC exploit clearly demonstrating code execution then i want them to mention that simple fact (i.e, 'change what they generate' as the current practice is outright coverup and/or using creative wording in the hope that somehow it'll evade people's mental detectors).
> I have never heard of a case where the kernel team has refused to accept
> a patch because it claimed to be a security fix,
strawman, it's never been about whether they accept a security fix (i think it'd even be criminal negligence if they refused to fix a security bug), but what they actually disclose with it, i.e., not mentioning the security relevance of a commit.
> what the kernel team has refused is to start tagging fixes as being
> security or not security fixes
you're wrong, check the commit log for CVE numbers and other known (and lesser known) keywords associated with security issues. the problem is that they used to do a better job at actually disclosing security bugs but have been playing the dumb for a few years now.
i also note you didn't answer what you, the security professional, would do if the world at large stopped disclosing security fixes, kernel dev style. that tells me much more about your (not) being a professional and/or (not) actually believing in your own arguments than any posturing here.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds