> and I am saying that trying to do this means that you will miss security
> fixes becouse at the time they were created nobody realized that they
> fixed security issues.
why does that imply that *known* security fixes shouldn't be marked as such? you're thinking in black&white terms again and again, and can't imagine that kernel security isn't one such thing.
> because of this good guys need to apply all the patches, not try to
> cherry-pick the ones that they think are 'important'.
no, they do not. in fact, judging by the amount of reverted commits, they're a lot better off by being careful. on the other hand i don't recall a security fix being reverted so their quality is a lot better than non-security fixes.
> If they want to do so (distros for example), they need to investigate
> _every_ patch to see if it has security implications or not.
they have to do it regardless for non-security implications as well.
> tagging some of them as having security implications strongly implies
> that ones that are not tagged do not have security implications, and
> that is incorrect.
why does it imply that? because you say so? ;) in the real world out there, people maintaining kernels for their users are not dumb and they know that any security labeling can at most be best effort, not a guarantee.
> even if all the commit says is 'this is important for security' the fact
> that the details of the fix are directly attached to the comment makes
> it pretty easy for the bad guy to focus their exploit effort.
why do you think they *need* such explicit marks to begin investigating a commit? think about it, a known security fix is very likely to get applied/backported by the good guys (i.e., its value is reduced for the attacker) whereas an unknown one (meaning, not known as a security fix at commit time) has a much better chance of remaining unfixed elsewhere therefore the bad guys already have to manually scan every commit *anyway*. not to mention the fact that they scan commits and find exploitable bugs in them when the bugs are introduced (think vmsplice or suid coredump), not when the security bugs are fixed. therefore it's really irrelevant for the bad guys whether the security fixes are marked or not. in fact, if there's any impact for them, they're probaly very grateful for the kernel devs for not marking security fixes because that increases their chances of exploiting a bug that is more likely to remain unfixed in their target's systems.
> I think that the reduction in effort is greater for the bad guys than it
> is for the good guys.
there's *zero* reduction in effort for the bad guys. if you have evidence otherwise, i'm all ears.