It's that people think they can drop Oracle on top of a crappy design and that will somehow magically fix it. By the time people get done trying to use brute force, ignorance and massive amounts of IT resources, you may as well have Dbase III on your back end. Oracle might let you get away with a shitty design if your application didn't really need a database, but it's not going to help you that much if what you're trying to do is complicated enough to need one.

heh and I see it was linked to in TFA. Sorry.

Ted Unangst wrote a good article called "analysis of openssl freelist reuse"

His analysis:

This bug would have been utterly trivial to detect when introduced had the OpenSSL developers bothered testing with a normal malloc (not even a security focused malloc, just one that frees memory every now and again). Instead, it lay dormant for years until I went looking for a way to disable their Heartbleed accelerating custom allocator.

it's a very good read.

That is the airlines problem.

The more workarounds a person finds for not travelling (calls, emails, etc.) the less the cost to the ticket buying company; assuming they manage to keep productivity the same.

You really don't want to know what robots do when they sit idle.

I assume the dues are tied to the estate of the person.

They're reclaiming it from the inheritance which should not have been passed down.

Dedupes client side.

You're with the NSA, right?

The TSA will just love that.

Shame about that child stepping out in front of you.

I have my own domains and do this with tunnelled rsync to a NAS4Free box, though for long term storage I like SpiderOak (and TarSnap). SpiderOak keeps historical versions and dedupes the data.

Try SpiderOak. Free 2 GB, zero-knowledge, secure. Works on a load of OSs and devices.

I'm a completely satisfied customer.

Just a minor correction - my piece does indeed suggest that the OpenSSL developers have some strange priorities. However, it lays the larger blame at the companies that used OpenSSL, when all the information necessary to suggest that this kind of thing could happen was already available, and the potential consequences for larger companies of a breach are easily enough to justify throwing a little money at the problem (which could have been used any number of ways to help prevent this).

I think we need to take a serious look at the "many eyes" theory because of this. Apparently, there were no eyes on the part of parties that did not wish to exploit the bug for close to two years. And wasn't there just a professional audit by Red Hat that caught another bug, but not this one?

I have to say I'm even less confident in the plan to couple it to DNSSEC.

Sure. We're better. But we need to be even better than that.