A /proc/PID/mem vulnerability

strawman and also an irrelevant tautology.

> As long as you can't reasonably know if to publish any hint of possible
> security impact or just keep it quiet is the better course of action.

real life says that you can reasonably know that there's an entire industry, both visible and invisible, out there that is watching and writing exploits as soon as they can get their hands on a bug, be that at bug commit time or later (the sooner the better as the value of 0-day beats anything else).

on the other hand the best course of action for users of said buggy code to save themselves is to fix the bugs (yes, i'm stating this myself despite being deeply involved in intrusion prevention technologies). for that they need to know about them, simple as that. covering up security fixes is diametrically opposite to that goal as it makes it much harder for users to reverse engineer the information from the commits whereas said industry has the brainpower to see through these silly attempts (as i said above, commits from Linus and certain other individuals draw immediate attention these days, witness what happened to this /proc/pid/mem bug).

btw, if you think keeping quiet about security impact information is the right course of action, what do you think about companies (linux vendors included) who do exactly that?

PS: i'm glad you stopped doubting that there *is* a coverup. you've come a long a way ;).