80b9edca1c11ec8118ab30451af9c1d492770c90

Posted Apr 25, 2011 0:46 UTC (Mon) by vonbrand (subscriber, #4458)
In reply to: 80b9edca1c11ec8118ab30451af9c1d492770c90 by PaXTeam
Parent article: Stable kernel 2.6.38.3

in general, it seems that you're arguing about something different (a strawman, as i never stated any of this): that kernel developers figure out whether a commit has a security impact or not. that's clearly neither their job nor competence, so i'm not sure why you keep raising this red herring. what i've been always talking about is that *if* they know that a commit fixes some security issue then they say so in the commit. do you understand the difference?

Yes, I do. And having a few patches flagged as security relevant (and the majority that is security relevant not so flagged) will just lead to all kinds of mud slinging ("They should have known!"); won't make the conspiracy theories go away; will have "smart" people just apply the "minimal, i.e. security relevant" set of patches and much moaning when they get pwned. Better not publicize incomplete, very fragmentary information that can turn out misleading. If you want to have security relevance for patches better do a decent job, or none at all, than a (less than) half-assed one.

80b9edca1c11ec8118ab30451af9c1d492770c90

Posted Apr 25, 2011 8:54 UTC (Mon) by PaXTeam (guest, #24616) [Link]

> And having a few patches flagged as security relevant [...] will just
> lead to all kinds of mud slinging ("They should have known!");

why would it lead to that (better cite some evidence)? do you see mud slinging for patches that are not marked as fixing e.g., a file system corruption bug? do you realize that security bugs caused by memory corruption can easily result in such damage as a sideeffect? would you not want to know about that?

> (and the majority that is security relevant not so flagged)

do you have any evidence for this or did you just make this up?

> won't make the conspiracy theories go away;

what conspiracy theories? what do they matter anyway? since when do someone's fringe theories control kernel development decisions?

> will have "smart" people just apply the "minimal, i.e. security
> relevant" set of patches and much moaning when they get pwned.

do you have evidence for the existence of such people? do you know how much of the linux userbase they represent? do you know if there're people who already do this? what would then change? if you think it's the kernel developers' job to protect 'smart' people from themselves, then they shouldn't make those commits available at all as no matter what they do, someone will always take it the wrong way. do you see where your thoughts would lead? death of open source as we know it.

> Better not publicize incomplete, very fragmentary information that can
> turn out misleading.

knowing that a bug fixes a security issue is neither incomplete nor fragmentary information, nor does it mislead anyone: applying a patch that does not in turn fix a security issue just a normal bug doesn't hurt anyone (this is what already happens today, you see).

> If you want to have security relevance for patches better do a decent
> job, or none at all, than a (less than) half-assed one.

there's nothing 'half-assed' in passing information down to the users that the developers already have. real world example: drugs used in medicine are known to have various sideeffects. these must be (by law, even) communicated to the patient. *but* there's no guarantee that *all* possible sideeffects are known for any given drug (we know in fact that some are discovered later, often much later after real damage has been done), yet that somehow doesn't prevent the *known* sideeffect information from being published. according to you, sideeffects of drugs must not be published because they are "incomplete, very fragmentary information that can turn out misleading".