> Linus isn't saying that they are the same when deciding what to fix, he
> is saying that when the fixes are completed and available they should be
> treated the same, no matter if they are known to be security problems or
when a non-security bug is fixed (say, one resulting in file system corruption), the commit explains what the issue was. when a security bug is fixed, it doesn't say so. how's that equal treatment?
> in part this is because many bug fixes end up fixing security problems
> that the author of the fix doesn't realize are there in the first place,
> so if you only apply fixes marked as 'security' you will not have a
> secure system.
why would anyone apply only explicitly marked security fixes? maybe one just wants to use that info for prioritizing fixes for backporting. second, why are you suggesting that by applying not only explicitly marked security fixes one will have a 'secure system' (such a thing doesn't seem to exist)? it's not about absolutes, it's about shades of grey: by being able to prioritize known security fixes one will have a *more* secure system, simple as that.
> other people think that someone should research all possible implications
> of every bugfix, and if it could be a security issue create a CVE number
> for it, and only after that submit the fix to be included.
you're leaving out the most common and obvious case: when the developer already knows that a bug is security related. what does it cost then to mention it in the commit? not even a CVE is needed for that.