if you worry about script kiddies (btw, for someone not bothering with
the whole security circus you surely do use their terms as bogeymen
to rationalize your stand) triggering or even exploiting local kernel
bugs then you imply that they're already local users on that box and
that in turn means they have already been having fun all that time.
just remember how Andrew put it:
But there are so many ways to cripple a Linux box once you have
local access. (http://lkml.org/lkml/2005/1/12/379)
in other words, try a better argument, possibly without bogeymen.
next, what about, say, sysadmins , bigger and smaller distro maintainers,
etc trying to figure out whether they need to backport a given fix or
not? do you think you're helping them too?
on a sidenote, what do you know about script kiddies? how do you think
they operate? do you think they're watching a real-time rss from kernel.org
to catch the latest and greatest security fixes? do you think they can
write PoC or actual exploit code based on commits?
last but not least, if i submitted a security fix with the commit message
actually saying that it fixes a security problem, would you remove that
information before committing? based on the above that sounds as a 'yes',
but i'd like to have that explicitly on the record.
people consider and backport patches that come to their attention,
which in turn happens by their scanning the changes, following various
threads of discussions (both public and private, depending on what they
have access to), etc. if you withhold security impact information then
you're skewing their 'big issue' detector as well, further reducing
*their* users' security.
i don't see you embargo normal bug fixes, why would you embargo security
bug fixes? they're just normal bugs, aren't they?
when you fix a bug, the commit describes what it fixes without omitting
anything relevant. when you fix a security bug, its commit doesn't say
what it fixes (not even that it's a security fix, never mind actual
impact information), that is, you omit relevant information (based on
some ill-conceived argument that i deconstructed at the beginning). in
other words, you're *not* treating security bugs as normal bugs. for
all intents and purposes, you cover them up. i *wish* you did treat
them as normal bugs however.
cheers,
Pax Team
--
