@ Dan Goodin,
Bruce, I'm surprised to read you downplaying the severity of the defects these researchers uncovered.
I don't think Bruce is within the context of this blog.
It is just one of many hundreds of similar "human errors" that occure with developers just about every day of the week. Which is why Bruce has in all likelihood said,
"It's hard for me to get too worked up about this vulnerability"
As others have noted it's not technically even an SSL issue but a more general "user issue" for developers implementing security applications.
To explain the difference,
You go out to your car get in put the key in the ignition and turn it and the car does not start.
If asked you would in all probability say "my car is broken down" which whilst it is true is unhelpful and in all likely hood incorrect technicaly.
What has happened is some small ancillary part of the car which actually does not prevent it being driven has let you down, such as the battery is flat (because you left the lights on) or the lock or switch mechanism has broken or come out of alignment (possibly due of you using excessive force) or a fuse has blown because you have drawn to much current from cold due to say using the cigarette lighter having the radio on loud and a seat warmer whilst trying to turn the engine over. It could also be that the solonoid that switches the high current to the starter motor has worked lose or become broken or the starter motor has stoped in a position it cannot start from so appears seized, neither of which is in use when the engine is running and the car is being driven by you.
Thus the probability is if the engine is turned over in some way (as used to happen with starter handles or when you jump a dead battery, or put a non auto into first gear and push start it) then the car would be quite drivable as long as you did not stop the engine.
So when to you your car won't start you say your car is broken with the incorrect implicit assumption it is not usable for it's primary purpose. A motor technician however knows that the car is in all probability functional for it's primary purpose it just needs either the circuit compleating or the starter motor unjamming or the battery jumping or a push start for you to drive it away.
Thirty years ago push starting, battery jumping and hand cranking were well known and many motorists new about them. These days however due to much additional complexity and increased reliability many drivers do not have any knowledge of such things.
And that's the point from a technical asspect this issue is the user (ie program developer) not knowing what to do when using the code library. And from this asspect it is so common it is very difficult to get worked up about.
However for a limited set of end users it might be a problem now but for most no. In a few days time a month or so or even a year or two it might not be a problem for the majority of end users. But I would expect the problem now it is known to become fixed in the next code release.
And this brings up another "user issue" within the accepted "custom and practice" user model. Unlike PC's with patch Tuesday and Auto Updates smart phones due in the main to the connectivity service providers and their charging models get neither patches or upgrades.
So your view point of it potentialy being a serious concern for end users is valid but misplaced for this blog. Because you have to also accept that from the technical view point it's just one more fairly yawn worthy human error amongst hundreds and from that respect would not normaly even make it onto this technical blog because there are other blogs (Krebs being just one of many) that do cater predominantly for the end user with patch/update alerts.
It is only that it does have some potential security asspects that Bruce has Bloged on it and has said,
"Great research, and -- yes -- the vulnerability should be fixed, but it doesn't feel like a crisis issue"
Which from a purely technical perspective is correct.
It should be the job of journalists and blog writers who cater specificaly to application developers who should be giving a heads up to their readers.
And in a little while it will be your job amongst many other more "end user focused" journalists and blog writers to make the end user aware that they realy should upgrade once each individual vulnerable package has been fixed and chase the developers if you think they are being to slow.
As in humour timing is very important in security,shouting loud now to end users before the developers have fixed an application or have had reasonable time to fix an application is actually going to be counter productive, in that they will hear you, find they cannot do anything and just ignore it in future when the patched application is available....