No... they SAID they cancelled this policy, immediately after it was brought to light. if they quietly reinstate in whole or in part... who would be the wiser? :)

I would also only be able to use EC cryptography with PFS with OpenSSL. I don't trust EC personally, yet. It's just not been around long enough for me.

The promise of PFS is that a private key compromised or lost after the fact does not compromise the contents of all sessions. Which means it's useless for an attacker to intercept thousands of SSH sessions, and then later make an attempt to break into the server --- they need private key at the time of any attack.

You're argument is the equivalent of saying "I would use SSH, but I just don't trust PAM yet for my password authentication, which SSH seems to require. So I'll keep on using Telnet."

By the way, ECDSA has been around over 10 years. In computer industry terms, that is quite ancient.

Which only tells us they're patched now, it doesn't tell them how much time the site was vulnerable.

That's true, BUT for the ones that are patched now --- the admin probably understands the issue. The sites with negligent, clueless, or sloppy admins, will be unpatched sites mostly (or sites running earlier releases before the vulnerable version).

Which only tells us they're patched now, it doesn't tell them how much time the site was vulnerable.

If they're patched now but were vulnerable 1 month ago; there is a pretty good chance >90% that the keys have not been stolen.

How can a black hole swallow a star if the star's clock slows to a stop as it approaches the event horizon?

It stops from the star's perspective, maybe. From the perspective of an outside observer: the star is absorbed into the blackhole and ceases to exist.

but according to Hawking, there is no event horizon as previously believed; just an apparent horizon.

what's next? researchers use beads to do arithmetic?

Next article is on how to use paper logarithm tables to perform calculations in a post-apocalyptic world.

You are correct about there being other IIS security vulnerabilities. There have also been other OpenSSL, Apache, and Nginx remote code execution vulnerabilities.

The Nginx RCE could also be used to compromise key storage.... could do even better than that, could load an eavesdropping trojan into memory.

The past IIS vulns did not necessarily easily compromise key storage.

The Heartbleed bug is MUCH easier to exploit than any RCE bug, even though the RCE bugs are more useful for an attacker, if a server is known to be vulnerable to one.

You would not believe what VP's will force you to do to get their $20 million flagship project out the door and then quickly forgotten about after the guy that was forced to do it quits in disgust.

Fraud that can get you in jail is not one of those things that some VP can force you to do.

The CA has to be validated by third party auditors, before it can even be trusted. One of the aspects that must be audited is the governance of that CA and the policies and controls of the CA designed to ensure the CA operates only according to the policies, and that would include that no system admin or member of management is capable of bypassing the rules.

GPL doesn't restrict people from using the software any way they want. It restricts them from preventing anyone else from using the software any way they want.

No... you're missing the big picture. It restricts the following use right: The right to use the code by modifying it and making a copy of the software and sell or give it to a friend or client, without giving the friend or client access to the source code.

Modifying the code and redistributing just the binary is one way of using the program. This use of the program is restricted by the GPL.

So the GPL does indeed restrict use.

You are prohibited from adding proprietary changes and keeping the nature and form of your changes confidential and protecting your rights to your changes and modifications.

pretty much every current web server cert in existence also needs to be revoked. Are the CAs even willing/able to do something on that scale in a short amount of time?

Calm down. A majority of web servers are not vulnerable and never were. All in all... less than 30% of SSL sites need to revoke any keys.

Some websites are running with SSL crypto operations performed by a FIPS140-2 hardware security module; these are not vulnerable, since OpenSSL doesn't have access to the private key stored in the server's hardware crypto token.

Many web sites are running on Windows IIS. None of these servers are vulnerable.

Plenty of web sites are running under Apache with mod_nss, instead of mod_ssl. None of the websites using the LibNSS implementation of SSL are vulnerable.

Many web sites are running on CentOS5 servers with Redhat's openssl 0.9.x packages. None of these servers were ever vulnerable.

Many web sites are running on CentOS6 servers, that had not updated OpenSSL above 1.0.0. These websites weren't vulnerable.

Many websites are running behind a SSL offload load-balancer; instead of using OpenSSL. Many of these sites were not vulnerable.

I'm sure some places will have their root CA on an externally connected machine, then try to place blame, likely saying how insecure UNIX is (when it isn't any particular flavor of UNIX that is at fault.)

Since this is in violation of the CA/Browser forum rules and Mozilla policies that pertain to trusted CA certificates; they are either lying, grossly negligent, OR both: if they have a root CA's private key ever loaded into an externally connected machine.

In fact.... a CA root certificate itself, is not a trusted certificate for ANY domain name. They'd have to go out of their way to compromise it --- such as by issuing a OCSP responder certificate with the same keypair.

the user of the keys should do this. Would you want to pay for new certs even if you were not affected by heartbleed?

It's within the CA's right, however, to scan the URLS certified by each certificate, test for Heartbleed vulnerability --- and automatically revoke, if they determine that the site is vulnerable.

Then perhaps Apple HAS given back significantly more than we know about?

3)if you want to redistribute it, in any way shape or form, give us credit

Yes... Unfortunately number (3) is a bit lost, for most redistributions of OSes or large software packages that happen to have BSD licensed elements --- there is no meaningful show of credit.

There used to be an advertising requirement in the original 4-clause BSD license, that would require mention of the developer's organization in advertising material --- but that bit got raped/essentially forced out, mainly due to the GPL being arbitrarily incompatible with it.

You can't stop someone from using the software the way they want.

Yes you can. You can release it under a restrictive license such as the GPL Version 3, then they either cannot legally use it, OR they must distribute the source back.

You can also choose a GPL-incompatible free software license with even more restrictions, if you like.