For someone like me, who has watched the repeated jabs at both OSX and Windows (mostly windows) from the open source crowd as to how (Ubuntu especially) is so much more secure...allow me just a moment or two to wallow in the glory of this. No system is without flaw, no system is without human-induced error. Late 2006 to now? Where's the much vaunted peer review of source code and packages? That's almost as long as it takes Microsoft to fix a patch. I hope this proves a humbling experience for those who have taken the holier-than-thou stance when it comes to thier OS of choice.

Has this EVER happened in closed source?

As SANS points out,

"Please keep in mind that SSL certificates should be regenerated as well. This can be even more problematic if you had your certificates signed since you'll have to go through this process again (and possibly pay money again)."

Ouch! That's gonna leave a mark!

May be I'll hold off on using any secure sites for a while to ensure they have a chance to mitigate this.

I am very dissappointed to hear about this security error. I have a comment regarding the question above, "Where's the much vaunted peer review of source code and packages?"

I don't know who found the error, or how they found it, but maybe it was found from a review of the source code. No? So, wouldn't that count as a peer review? Although 2 years does sound like a long time. At least they seem to be fixing it fast - I already downloaded the patches.

Regards.

http://wiki.debian.org/SSLkeys explains in great detail the scope of the vulnerability as well as it's introduction and response from the upstream developers. Review it before making assumptions about your local system.

I am very dissappointed to hear about this security error. I have a comment regarding the question above, "Where's the much vaunted peer review of source code and packages?"

I don't know who found the error, or how they found it, but maybe it was found from a review of the source code. No? So, wouldn't that count as a peer review? Although 2 years does sound like a long time. At least they seem to be fixing it fast - I already downloaded the patches.

Regards.

"Where's the much vaunted peer review of source code and packages?"

Charle's is trolling. Whoever the "Open Source" crowd are, I expect they know that OSX is based on a lot of open source software and has a good security record.

This bug was introduced in Debian as part of changes to enable better security audits of code that use this library. Ironic but true.

The change wasn't made lightly, and likely the best testing methodology to spot this kind of error would have been a regression test (rather than peer review) that ensured the entropy collection was still effective. Since entropy collection is a core part of the cryptography used, it should have a test case.

The bug needs media attention, and is news worthy, more because of its impact on SSH keys than x509 certificates used for e-Commerce.

The effect of secure site certificates for websites is that the encrypted traffic to a website can be decoded if you know what you are doing and have access to the passing traffic. In most cases folks with that sort of access can subvert the communication by other means. The eCommerce padlock has long been a bit of a joke in computer security as it (usually) provides top notch security for communication between to relatively easily compromised devices.

The SSH key issue means any computer that trusts these types of keys for authorization probably wants to be using a blacklist tool.

More irony, but Debian and Ubuntu are probably more secure, not less, right now - since they now have a method to spot the use of these vulnerable keys that other vendors haven't yet rolled out because of the perception that it is a Debian problem, rather than understanding that it is a problem with cryptographic material created on certain versions and derivatives of the Debian openssl package.

"Has this EVER happened in closed source?"

Bugs in PRNG/randomness are a perpetual bane of all security systems, and that initially shipped in Windows XP and Windows 2000 were noticeably poor in a similar fashion.

I'm not aware of bugs that resulted in bulk reissuing of certificate. Although it is quite possible some similar issues should have resulted in such but the vendor forgot to mention it.

What is most troubling here is the lack of code review that ALLOWED this change in the first place!

Someone at quality control needs to burn for letting this through. It's hardly some obscure little tool that no-one uses, it needs as tight control as any other core element like, oh say, the kernel.

Don't they have any controls in place? Forget the fact that a little testing could have caught this, but some impact analysis way before the fact would have prevented this before a line of code was changed. This is a rookie mistake, and any decent experienced developer would have consulted with some peers before taking this kind of action. The main blame here is on the process or the lack of it in this case.

Whoever did this should not have had absolute authority to do this, and the people to blame are the ones who put him in this position, but he should have known to go over this first.

The main thing is that people shouldn't mindlessly change code to please a tool. The tools are not there to tell you what to do; they're just there to help you find problems by reporting what they consider to be potential problems. Ripping out code without knowing what it does is so stupid it defies belief.

OMG. A line of code is acting up so just take it out? OMG OMG. To quote Simon: it's so stupid it defies belief. Welcome to the New Millennium where no one breaks into a sweat, no one studies, no one spells - and where consequently where the bad buys finally get the upper hand.