User: Password:
|
|
Subscribe / Log in / New account

2.6.32.9 Release notes

2.6.32.9 Release notes

Posted Feb 22, 2010 5:57 UTC (Mon) by spender (subscriber, #23067)
In reply to: 2.6.32.9 Release notes by bojan
Parent article: 2.6.32.9 Release notes

Let them have their straw men. People like clugstj who keep bringing up and attacking things that no one on the "complaining" side has said are people that haven't listened to a single word for the past 2 years. I'm curious what form of Linux these anti-complainers are using -- since they act as if this issue doesn't affect Linux users at all.

I'd also like to say something about the last paragraph of the article. "Those who would complain about how the stable tree is managed" "do well to remember" a few years ago when Chris Wright was involved in the stable releases as well. The official policy was different back then, and it's gone downhill since he stopped being involved. As for insinuating that the complainers (which would include me) haven't stepped up to offer time/energy, I'd like to point out that in July 2008 around the time when this issue was first heavily debated, the PaX Team and myself offered our free time to do similar cursory write-ups on the stable releases. Jake had presented the idea to us and said it would be hosted on LWN. Nothing had ended on a sour note, but the last email we received about it was the day after the first email we received about it. We didn't hear anything else back until we asked about it ourselves again in January of 2009. Apparently in the meantime Jake thought "it might not be very productive" and failed to inform us that he scrapped the idea.

Like Eugene mentioned, some of us are putting forth the effort to bring some honesty to the security of the kernel. If you look at Linus' ridiculous changelog message for move_pages(), at the lengths he went through to take the accurate, useful information he was given and turn it into something pointlessly obfuscated (when the two line fix screams of fixing completely nonexistent bounds checks), you'll understand why the work of the "complainers" is important. It's surprising, actually, given Linus' hatred for embargoes -- he wants users to have the security bugs fixed and not have to wait an arbitrary amount of time for it. How does he expect these fixes to get back to actual users if he actively works to hide them?

Seriously, look at it:
>From: Linus Torvalds <torvalds@linux-foundation.org>
>
>commit 6f5a55f1a6c5abee15a0e878e5c74d9f1569b8b0 upstream.
>
>We incorrectly depended on the 'node_state/node_isset()' functions
>testing the node range, rather than checking it explicitly. That's not
>reliable, even if it might often happen to work. So do the proper
>explicit test.
>
>Reported-by: Marcus Meissner <meissner@suse.de>
>Acked-and-tested-by: Brice Goglin <Brice.Goglin@inria.fr>
>Acked-by: Hugh Dickins <hugh.dickins@tiscali.co.uk>
>Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
>
>---
> mm/migrate.c | 3 +++
> 1 file changed, 3 insertions(+)
>
>--- a/mm/migrate.c
>+++ b/mm/migrate.c
>@@ -953,6 +953,9 @@ static int do_pages_move(struct mm_struc
> goto out_pm;
>
> err = -ENODEV;
>+ if (node < 0 || node >= MAX_NUMNODES)
>+ goto out_pm;
>+
> if (!node_state(node, N_HIGH_MEMORY))
> goto out_pm;

I can imagine fixes for buffer overflows being worded like:
"We incorrectly depended on strcpy for testing the array size, rather than checking it explicitly. That's not reliable, even if it might often happen to work. So do the proper explicit test."

-Brad


(Log in to post comments)

2.6.32.9 Release notes

Posted Feb 22, 2010 10:57 UTC (Mon) by tialaramex (subscriber, #21167) [Link]

"the PaX Team and myself offered our free time to do similar cursory write-ups on the stable releases"

It's not clear from this whether you merely offered (it's easy to offer) or whether you actually did it. If you did, links please? It might be interesting to see whether your attempts were any better than our esteemed editor.

2.6.32.9 Release notes

Posted Feb 22, 2010 11:23 UTC (Mon) by PaXTeam (guest, #24616) [Link]

> If you did, links please?

it was a private discussion via email and i think i'm not at liberty to quote it without consent but if the other participants agree to make them public, so do i.

2.6.32.9 Release notes

Posted Feb 22, 2010 12:44 UTC (Mon) by tialaramex (subscriber, #21167) [Link]

Maybe I didn't make myself clear, I am asking if these "cursory write-ups" actually exist. It seems not. Obviously any number of people could volunteer to write such things, but that's worthless unless they actually do it.

The write ups themselves would not constitute part of a "private discussion"

2.6.32.9 Release notes

Posted Feb 22, 2010 13:38 UTC (Mon) by PaXTeam (guest, #24616) [Link]

> Maybe I didn't make myself clear,

no, you were just being dense as usual. try to read the sentences next to what you quoted and understand that the whole effort sort of died down and not because we wanted it.

> I am asking if these "cursory write-ups" actually exist.

i can't speak for spender here but i keep my own logs on various commits here for stuff that i find relevant for myself (not necessarily security related either). but that's a private list and not what we were going to publish.

> It seems not.

it seems you're just trolling as usual. but if you want to get a taste of what was going to be published, read spender's twitter stream where he pointed out several silently fixed security bugs over the past months, many if not all of them without a CVE at the time. reminds me, did the sparc64 NX bug get a CVE already?

> The write ups themselves would not constitute part of a "private discussion"

what's private and what's not is not for you to decide.

2.6.32.9 Release notes

Posted Feb 22, 2010 17:39 UTC (Mon) by vonbrand (guest, #4458) [Link]

I'm sorry, but you claim to be doing the work of travelling the patches and checking them for security relevance, and do not publish the results, while complaining others don't publish the very same data (which they arguably don't have at hand)?

I just can't imagine our esteemed editor refusing a volunteer column like the article we are talking about here.

2.6.32.9 Release notes

Posted Feb 22, 2010 19:10 UTC (Mon) by PaXTeam (guest, #24616) [Link]

> I'm sorry, but you claim to be doing the work of travelling the patches

some commits, yes.

> and checking them for security relevance,

i mostly check them for interference with my work and that necessarily means that sometimes my eyes catch security relevant commits as well.

> and do not publish the results

i don't understand what is there to publish. aren't all bugs just bugs? what else do *you* want to know about them? you can't defend the coverup of security bugs and complain about their lack of disclosure at the same time. make up your mind ;). also you're welcome to follow spender's twitter stream, we often inform each other about suspicious commits and investigate together.

> while complaining others don't publish the very same data (which they arguably don't have at hand)?

i never complained about not disclosing security impact information they do not themselves have already. quote me back if you believe otherwise. what i did and still do complain about is when they *know* that a commit fixes a security bug but cover it up.

> I just can't imagine our esteemed editor refusing a volunteer column like the article we are talking about here.

it wasn't him (Jon) and it wasn't going to be part of LWN but rather a reply to -stable postings on lkml (spender went back and double checked the emails).

2.6.32.9 Release notes

Posted Feb 22, 2010 19:32 UTC (Mon) by nix (subscriber, #2304) [Link]

Now, now, spender at least publishes the results by emailing md5sums of
descriptions of bugs to people. Surely that is sufficient for anyone.

</snark>

2.6.32.9 Release notes

Posted Feb 22, 2010 17:45 UTC (Mon) by vonbrand (guest, #4458) [Link]

I fail to see any problem with the changelog entry. A range test was mistakenly omited, add it. Sure, this particular missing range check can have disastrous consecuences, just as there are probably a dozen others added the same way that are "can't happen"s or have little or no impact. The log entry describes what was wrong with the code, as it should.

2.6.32.9 Release notes

Posted Feb 22, 2010 19:33 UTC (Mon) by nix (subscriber, #2304) [Link]

I think Linus went a bit far here. He was actually *told* that it would
have disastrous consequences, and shown how: he should probably have
mentioned as much in the log message. This did seem to be played down
entirely too much for my liking.

2.6.32.9 Release notes

Posted Feb 22, 2010 20:36 UTC (Mon) by bojan (subscriber, #14302) [Link]

On the funny side of things, the 2.6.32.8 release reads like a plot of a Monty Python skit: a security problem was fixed after intensive scrutiny, but we don't know which one it was. Hilarious! :-)

2.6.32.9 Release notes

Posted Feb 22, 2010 19:07 UTC (Mon) by clugstj (subscriber, #4020) [Link]

It's not a straw man. I'm too lazy to look it up, but nearly every time that there is a security problem in a kernel update, someone belly aches that the kernel developers should figure out for if this bug is a security problem for them.

It's very hard work to do this even in the general case. I'd much rather the kernel developers spend their time FIXING bugs than trying to imagine the possible uses a black hat could have for it.

I didn't point anyone out explicitly, but it does appear that I hit a nerve.

2.6.32.9 Release notes

Posted Feb 22, 2010 19:22 UTC (Mon) by spender (subscriber, #23067) [Link]

Not only are you too lazy to look it up, but if you try you won't find anything. I did a simple search for you, so you can see what we've said *repeatedly* and exactly why you're attacking a straw man.

http://lwn.net/Articles/286263/
"Willy, please do read the previous discussion before commenting. the problem isn't that people are unable to determine whether a given bug has a security impact or not. that is a separate issue and is not the point raised now. the problem we exposed is that of covering up security impact information when it *is* already known to the kernel developers."

"2. as you were told about a dozen times already, the problem isn't with not recognizing a bug for its security impact (or rather, that's a separate problem), but the intentional omission of such information when it is already known."

http://lwn.net/Articles/290570/
"yes, it would be the next step after the already known security issues are acknowleged at least."

http://lwn.net/Articles/373731/
"And again, before anyone brings it up again, it's not about the developers themselves trying to figure out if every bug is a security bug -- it's about not hiding or obfuscating what they are clearly aware of."

"If you don't omit the security information you're aware of, nothing changes on the blackhat side because they can already spot developer weasel words when the developers are committing a vulnerability fix."

I look forward to your apology.

-Brad

2.6.32.9 Release notes

Posted Feb 22, 2010 20:16 UTC (Mon) by clugstj (subscriber, #4020) [Link]

Pardon me if I don't believe your "search" - it could be a bit biased. Why would I apologize to you? Did I mention you or the others going bonkers in this thread by name at any point in this discussion?

If you told a kernel developer that such and such a bug has this security impact, why should he automatically believe you? Unless he very much trusts your opinion or has the time to check your findings, he would be foolish to do so.

I made the original comment for two reasons:

1) I have seen the kind of comment of which I speak. I never said it was from you, nor did I have you in mind.
2) I don't mind stirring the pot.

2.6.32.9 Release notes

Posted Feb 22, 2010 20:24 UTC (Mon) by bojan (subscriber, #14302) [Link]

> If you told a kernel developer that such and such a bug has this security impact, why should he automatically believe you?

Er, because he found and wrote exploits for quite a few security problems in the kernel?

2.6.32.9 Release notes

Posted Feb 25, 2010 13:52 UTC (Thu) by vonbrand (guest, #4458) [Link]

Please stop this nonsense. If Linus (or whoever) knows about the possible security implications of, let's say, 10 or 20% of the bugs, and only marked those, the majority of security sensitive bug patches would just be ignored by would-be "experts", and the whining about the other "not reported" bugs would start whenever some box gets broken into...

A bug in the kernel is potentially extremely serious, go and fix it. Questions are optional, patching isn't.

2.6.32.9 Release notes

Posted Feb 25, 2010 14:55 UTC (Thu) by PaXTeam (guest, #24616) [Link]

> If Linus (or whoever) knows about the possible security implications of,
> let's say, 10 or 20% of the bugs, and only marked those the majority of
> security sensitive bug patches would just be ignored by would-be "experts"

stop that nonsense. you have zero evidence for it. in the previous thread a kernel developer only offered anecdotal evidence which is of course as good as mine or anyone else's. you might want to understand who patch users are too: http://lwn.net/Articles/374094/ . also you might want to explain why file system corruption bugs are marked as such in commit messages whereas there's no guarantee that unmarked commits don't fix file system corrupting bugs.

> A bug in the kernel is potentially extremely serious[...].

it depends on the bug. and as we learned from local experts here, it also depends on what one considers a bug at all ;).

> Questions are optional, patching isn't.

you've never really had a real job, have you.

2.6.32.9 Release notes

Posted Feb 25, 2010 20:44 UTC (Thu) by nix (subscriber, #2304) [Link]

Filesystem corruption bugs are marked as such *if people realise at fix
time that they are filesystem corruption bugs*.

Not all filesystem-corrupting bugs are recognised as such at fix time,
just like not all security bugs are recognised as such. (It is probably
easier to detect a filesystem-corrupting bug than a security bug, because
at least there are broad regions of the kernel where bugs are unlikely to
affect filesystems, which is not true for security holes.)

btw, nice to see you're vilely rude to everyone, not just me (and fifty
seconds' googling would make it clear that he's had multiple real jobs in
the free software community. He gives out his real name, you see.)

2.6.32.9 Release notes

Posted Feb 25, 2010 22:42 UTC (Thu) by PaXTeam (guest, #24616) [Link]

> *if people realise at fix time that they are filesystem corruption bugs*.

aha. and "if people realise at fix time that they are security bugs" they... don't mark them as such. not only that, they even try to explain why that's a good thing. now you tell me why the same arguments don't apply to filesystem corruption bugs (and many others, i just picked an obvious one for this exercise). or more to the point, why the arguments for marking known filesystem corruption bugs don't apply to known security bugs. btw, i'm glad that after years of misunderstanding you're slowly getting it ;).

> [...]because at least there are broad regions of the kernel where bugs
> are unlikely to affect filesystems,

anything that can result in kernel memory corruption, in those broad regions of the kernel included, has a fair chance to trash filesystem related (meta)data as well. speaking of which, by the same token if said memory corruption bugs are not marked for security, they should at least be marked for potential filesystem corruption but not even that is done.

> btw, nice to see you're vilely rude to everyone, not just me

i wasn't rude to you, you yourself admitted that you sometimes post under the influence of drugs that you later regret. i was merely wondering if the same happened here as well because you so obviously posted crap about something that wasn't ever said (you're welcome to prove your post with quotes from us).

> (and fifty seconds' googling would make it clear that he's had multiple
> real jobs in the free software community.

make it 5 seconds, but then we've got bigger skill differences i guess ;). and yes, i know where he teaches and it's also clear that he has no idea whatsoever about how a real corporation works where people have real responsibilities and the "Questions are optional, patching isn't" mentality doesn't fly in *any* production environment i've ever seen (hint: it's not how RH/Novell work either). but someone like you should know better than defending such a stand.

> He gives out his real name, you see.

this coming from an anonymous coward sounds just way too funny ;).

2.6.32.9 Release notes

Posted Feb 25, 2010 23:09 UTC (Thu) by nix (subscriber, #2304) [Link]

aha. and "if people realise at fix time that they are security bugs" they... don't mark them as such.
And I agree that that is a bad thing, and have said so repeatedly, although I'd understand it if you were too busy sniping to actually read what I write.

2.6.32.9 Release notes

Posted Feb 22, 2010 19:28 UTC (Mon) by PaXTeam (guest, #24616) [Link]

> It's not a straw man.

it is as none of us made such a claim you're trying to push here, in fact every time this comes up we make a claim to the contrary: kernel devs are not expected to figure out the security impact of bugs because they're not qualified to do so. just look at Jon's effort here and how he missed #1 and mischaracterized #2.

> I'm too lazy to look it up

you're not lazy to look it up, you're unable to but needed a convenient excuse.

> but nearly every time that there is a security problem in a kernel update

you're welcome to find a *single* post from us that makes a claim you wish to attribute to us. after all, if it was 'nearly every time' you won't have to spend more than a few seconds to find one.

> someone belly aches that the kernel developers should figure out for if this bug is a security problem for them.

we never made such a claim, and in fact i don't recall anyone else making it either. but the onus is on you to back up your statement.

> I didn't point anyone out explicitly, but it does appear that I hit a nerve.

considering the amount of trolling and shouting from you, i know whose nerve was hit ;).

2.6.32.9 Release notes

Posted Feb 22, 2010 20:22 UTC (Mon) by bojan (subscriber, #14302) [Link]

> It's not a straw man. I'm too lazy to look it up, but nearly every time that there is a security problem in a kernel update, someone belly aches that the kernel developers should figure out for if this bug is a security problem for them.

I certainly never asked for anything like that.

So, once again: if it is known, it should be passed on. That's it.

2.6.32.9 Release notes

Posted Feb 22, 2010 20:25 UTC (Mon) by clugstj (subscriber, #4020) [Link]

Guys, get over yourselves. When did I mention anyone by name?

2.6.32.9 Release notes

Posted Feb 22, 2010 20:33 UTC (Mon) by bojan (subscriber, #14302) [Link]

Just making sure that "someone" doesn't include me.

2.6.32.9 Release notes

Posted Feb 22, 2010 21:41 UTC (Mon) by PaXTeam (guest, #24616) [Link]

if you weren't just trolling then you can name at least one of those 'whiners'. with actual proof of that whining to back it up of course. should be easy since "nearly every time that there is a security problem in a kernel update, someone belly aches that the kernel developers should figure out for if this bug is a security problem for them".

2.6.32.9 Release notes

Posted Feb 22, 2010 20:25 UTC (Mon) by jake (editor, #205) [Link]

> Apparently in the meantime Jake thought "it might not be very
> productive" and failed to inform us that he scrapped the idea.

(sorry for the late reply, I was travelling back from SCALE)

At around the same time as we were discussing the idea, there was a flamewar about the same subject going on in lkml and it seemed clear to me that the personalities involved (on both sides) would likely just perpetuate that. That's why I didn't think it would be very productive, fwiw.

But I certainly don't discourage information about the known security impacts of stable tree patches (or any other patches for that matter) being published. If it were, we would be likely to link to it.

jake

2.6.32.9 Release notes

Posted Feb 22, 2010 21:24 UTC (Mon) by nix (subscriber, #2304) [Link]

This thread is surely proof of your expectation. The usual suspects are
flaming and alleging bad faith and incompetence in a thread responding to
a post doing *exactly what they've been bellyaching about for years*.

It is quite plain by this point that they are impossible to satisfy.

2.6.32.9 Release notes

Posted Feb 22, 2010 21:36 UTC (Mon) by PaXTeam (guest, #24616) [Link]

did hayfever season come early? how about you actually read the posts you're supposedly forming your utterly uninformed opinion about ;).

2.6.32.9 Release notes

Posted Feb 22, 2010 23:06 UTC (Mon) by nix (subscriber, #2304) [Link]

Amazing. Whenever I thought I'd seen you be the acme of unpleasantness,
you beat your record.

I *really* want a killfile for LWN. There'd only be two names on it for
me... hm, actually, three, petegn deserves to be on it too.

2.6.32.9 Release notes

Posted Feb 22, 2010 23:56 UTC (Mon) by spender (subscriber, #23067) [Link]

You could always pretend as if such a killfile existed. I would welcome this change!

Sincerely,
-Brad

2.6.32.9 Release notes

Posted Feb 23, 2010 4:03 UTC (Tue) by chad.netzer (subscriber, #4257) [Link]

Perhaps a Greasemonkey script can be whipped up for those of us who feel
that the ridiculous pretentiousness of spender, PaxTroll, bojan, et al. are
ruining LWN discussions?

Comment filtering

Posted Feb 23, 2010 4:23 UTC (Tue) by corbet (editor, #1) [Link]

A comment filtering mechanism is in the works, has been for a little while. I hope that people won't use it much, though; it would be better if we could express our disagreements in a more respectful manner...

Comment filtering

Posted Feb 23, 2010 6:44 UTC (Tue) by bojan (subscriber, #14302) [Link]

> it would be better if we could express our disagreements in a more respectful manner...

Is this directed to the above mentioned "pretentious" people? If yes, could you please point out which of my comments was disrespectful here?

Comment filtering

Posted Feb 23, 2010 13:56 UTC (Tue) by corbet (editor, #1) [Link]

It was not directed at anybody in particular, believe it or not. I just wish, in general, that the tone of the conversation would be a bit more respectful and that people would focus more on the issues and not other people...

Comment filtering

Posted Feb 23, 2010 19:09 UTC (Tue) by chad.netzer (subscriber, #4257) [Link]

And though I listed you as "pretentious", I would not put you in the same
class as PaxTroll or spender, who go out of their way to be condescending
primadonnas. And corbet would likely label me as disrespectful in these
comments (it's true; I do *not* respect the above two I mentioned).

The LWN comment section is not well suited to these kinds of opinionated
"discussions", since there are no tools to control the threading, collapsing
and rating of comments, etc. Hence, the same points keep getting
fruitlessly reargued. Not sure its fixable, but a simple filter *might* help
with signal to noise for those that want to have a novel discussion.

Meanwhile, I'd rather talk about things like which of these fixes actually
solve an issue for people. We have been testing #36 for a short while,
since the umount bug it fixes was actually hitting us in practice. It'd be
nice to talk about something like who here is actually using and testing the
2.6.32.y series, and what issues have they had?

Comment filtering

Posted Feb 23, 2010 23:50 UTC (Tue) by nix (subscriber, #2304) [Link]

2.6.32.x has actually been by far my least problematic kernel series in
ages. 2.6.31 had e1000e flow control lossage for me, and a couple of
oopses, rapidly fixed; 2.6.30 had e1000e 82574L jumbo frame lossage and a
single unreproducible incident of massive ext4 filesystem corruption (well
I say 'massive' but fsck fixed it completely: it just took it half an hour
of flooding messages across the screen). 2.6.32 has had nothing wrong at
all, other than an obscure and hard-to-track-down intel-hda ALSA bug,
exhibited only by PulseAudio complaints.

... or, rather, the only wrong thing is an explosion of almost totally
idle ext4 direct I/O kernel threads: one per CPU per sb. That's 96 or
something on my machine. I only want direct I/O for *one filesystem*
dammit!

2.6.32.9 Release notes

Posted Feb 23, 2010 7:02 UTC (Tue) by bojan (subscriber, #14302) [Link]

Maybe you like accepting a view given to you by Linus and other kernel developers as is. I find it confusing and illogical.

First, they tell us that all bugs should be considered "normal bugs": http://kerneltrap.org/Linux/Security_Bugs_and_Full_Disclo....

Then in 2.6.32.8 (http://lwn.net/Articles/373579/), just a while ago, we are told that, yes, there are security bugs. But, we cannot know which ones they are, although kernel developers already know, because they took special steps to make sure they were properly backported and tested.

In the meantime, we are STRONGLY encouraged to upgrade. Why strongly? Why not just normally? After all, security bugs are just normal bugs, right?

Now, please, tell me what is pretentious about asking to square up the above? I do not see how both can be true. Either security bugs are special (given that kernel developers are obviously giving them special treatment) or they are not. Also, if they already know about them, why can't we be told?

2.6.32.9 Release notes

Posted Feb 23, 2010 22:09 UTC (Tue) by nix (subscriber, #2304) [Link]

I think you got that backward. It's not that security bugs are normal
bugs, therefore security bugs are as unimportant as normal bugs: it's that
in an unprotected environment like the kernel, almost any bug could
potentially be a security bug (although it might be hard to exploit if,
say, it requires module unloading to trigger). i.e., normal bugs are
potentially as important as security bugs -- but it is quite impractical
to consider them *actually* as important as security bugs, because so very
many bugs are fixed all the time. They're merely *potential* security
bugs. And this is true of most bugs when they're fixed.

I don't agree with Linus that bugs that are *known* to be security bugs at
the time they're fixed shouldn't be called out as such and backported. I
do agree that it's impractical to expect the security implications of all
bugs to be spotted by the person who fixes them at the time the fix is
made: even if it is obvious to a steeped-in-security guy like spender, it
may not be obvious to everyone.

I'd assume that everyone involved in kernel programming knows how bad
buffer overruns and wild pointer dereferences are. After the recent
palaver I'd hope they'd know that NULL pointer dereferences are bad too.
But there are lots of other classes, and some are rare enough that I
wouldn't know them if I saw them, and might not even know them if they
were pointed out to me. (This is where spender's published exploits are
especially useful to whitehats, IMNHSO: for didactic purposes. He puts
comprehensible comments in the damn things! You can use any random
blackhat's exploit to see if your machine is vulnerable, but if you want
to know how that class of exploit works, and thus why the vulnerability is
a vulnerability, you need more than a pile of incomprehensible uncommented
shellcode.)

2.6.32.9 Release notes

Posted Feb 23, 2010 22:36 UTC (Tue) by bojan (subscriber, #14302) [Link]

> I think you got that backward. It's not that security bugs are normal bugs, therefore security bugs are as unimportant as normal bugs:

Not my words, actually. Directly from Linus:

"I personally consider security bugs to be just 'normal bugs'. I don't cover them up, but I also don't have any reason what-so-ever to think it's a good idea to track them and announce them as something special."

> it's that in an unprotected environment like the kernel, almost any bug could potentially be a security bug (although it might be hard to exploit if, say, it requires module unloading to trigger). i.e., normal bugs are potentially as important as security bugs -- but it is quite impractical to consider them *actually* as important as security bugs, because so very many bugs are fixed all the time. They're merely *potential* security bugs.

Completely agree.

> I don't agree with Linus that bugs that are *known* to be security bugs at the time they're fixed shouldn't be called out as such and backported.

And that is the crux of the issue here. What is being asked is actually quite simple. If the kernel developers know it's a security issue (by determining that themselves or by being told by someone experience in security), they should tell the rest of us. No extra effort required.

All other bugs, of course, can still turn out to be security issues. Such is kernel life, I guess. I'd say everyone is aware of that by now.

2.6.32.9 Release notes

Posted Feb 27, 2010 6:30 UTC (Sat) by malor (guest, #2973) [Link]

Yeah.... I, for one, totally don't expect them to spend a bunch of extra work figuring out if something is a security problem. But I DO expect them to pass along if it's a confirmed security issue if they already know about it. Deliberately obfuscating that information only hurts me. It can't possibly help. The ONLY thing it "helps" is that people get less pissed about security holes.

Having the same number of actual bugs, but being less aware of security holes, is actively dangerous. I consider it egregious behavior to deliberately mislead people about the nature of security fixes.

2.6.32.9 Release notes

Posted Feb 22, 2010 21:46 UTC (Mon) by bojan (subscriber, #14302) [Link]

> It is quite plain by this point that they are impossible to satisfy.

What is impossible to satisfy is illogical explanations about why things that were known to be security problems never got disclosed as such. The latest obfuscation by Linus is a clear case in point. The announcement of the .8 release is another.

If something as implemented is nonsense, expect questions. Waving a magic wand in the hope that these questions will vanish won't work. Neither will same illogical explanations.

2.6.32.9 Release notes

Posted Feb 22, 2010 21:37 UTC (Mon) by PaXTeam (guest, #24616) [Link]

> But I certainly don't discourage information about the known security
> impacts of stable tree patches (or any other patches for that matter)
> being published. If it were, we would be likely to link to it.

what form of disclosure would you link to? twitter? web forum? email archive?

2.6.32.9 Release notes

Posted Feb 22, 2010 21:48 UTC (Mon) by jake (editor, #205) [Link]

> what form of disclosure would you link to? twitter? web forum?
> email archive?

i think it would be difficult to link to individual twitter messages about each problem as it was noted (and i don't know that twitter gives enough room for context and such), but some kind of summary in a web forum or page, mailing list posting, or whatever would (obviously) be of interest to our readers.

jake


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds