Earlier quoted context omitted.
Which of the assertions in the post do you disagree with?
I think it's reasonable to disagree with the part he quoted. "A review by a security engineer ..." Well, it was reviewed by security engineers, and the false sense of security remained. The rest seems fine though.
Willem Pinckaers on Akamai's flawed OpenSSL allocator patch
71–79 of 79 posts
Re: Willem Pinckaers on Akamai's flawed OpenSSL allocator patch
#72Earlier quoted context omitted.
> Comes across quite passive aggressive indeed. Oh so what. Tone arguments are the least interesting arguments (he says, passive aggressively). In seriousness though, this is a blunt assessment from an expert in the field. The tone is entirely appropriate. > No good deed goes unpunished. Akamai strongly implied that their patch protected customers . If you make that claim then you need to be prepared to have the clai…
> Akamai strongly implied that their patch protected customers. Actually they said exactly the opposite of that: > This should really be considered more of a proof of concept than something that you want to put directly into production. Let me restate that: do not just take this patch and put it into production without careful review.
> This patch is a variant of what we've been using to help protect customer keys for a decade.
1. From the original Akamai missive: http://article.gmane.org/gmane.comp.encryption.openssl.user/...
Re: Willem Pinckaers on Akamai's flawed OpenSSL allocator patch
#73Earlier quoted context omitted.
This post isn't simply "ridiculing" the proposed allocator design. Did you work on this allocator? If not, can I suggest that you be a little careful? It's one thing to stick up for Akamai's developers; it's another to be thin-skinned on their behalf. It's possible that Akamai's devs, being adults, professionals, and engaged with software security, actually want to hear Willem Pinckaers' take on their allocator.
Speaking as a security researcher at Akamai, I can say that tptacek is 100% correct here. We're absolutely better off for having received Willem's report, and I'm pretty sure we're all mature enough to tolerate the jabs that accompanied it. I didn't have any part in writing this allocator, but I was asked to do a code review prior to publication. I told Rich Salz that it would take me at least two days to do a thorou…
Re: Willem Pinckaers on Akamai's flawed OpenSSL allocator patch
#74With enough eyeballs, all bugs are indeed shallow!
Re: Willem Pinckaers on Akamai's flawed OpenSSL allocator patch
#75Re: Willem Pinckaers on Akamai's flawed OpenSSL allocator patch
#76A review by a security engineer would have prevented a false sense of security Everyone involved in this, from the people who wrote the heartbeat code, the people who committed the code, the people at Akami who wrote this patch, this poster ... all would describe themselves as security engineers. Is everyone but Willem Pinckars incompetent? I think the one lesson to learn is to treat crypto just like you do cloud pro…
I don't think I've worked anywhere where there was a simple way to switch cloud providers with the push of a button. Even migrating to different locations within a cloud provider isn't trivial. You'd have to invest a lot of engineering time from the beginning to get this kind of capability, and you may never realize any value for all the pain.
Re: Willem Pinckaers on Akamai's flawed OpenSSL allocator patch
#77Earlier quoted context omitted.
Nope. As long as they don't distribute it but only run it in a server, they don't have to. This is what the AGPL is changing.
Not here: you can't do much with AGPL+OpenSSL. AGPL requires release under AGPL. OpenSSL requires advertising clause. There is no legal way to distribute software including parts you have only under APGL and parts you have only under OpenSSL license.
If you modified AGPL code you have to release it. If you've mixed up GPL or AGPL code such that you can't release it you've violated the license for the hard work of others. You sound confused, to phrase it charitably.
Re: Willem Pinckaers on Akamai's flawed OpenSSL allocator patch
#78Earlier quoted context omitted.
Not here: you can't do much with AGPL+OpenSSL. AGPL requires release under AGPL. OpenSSL requires advertising clause. There is no legal way to distribute software including parts you have only under APGL and parts you have only under OpenSSL license.
> There is no legal way to distribute software including parts you have only under APGL and parts you have only under OpenSSL license. If you modified AGPL code you have to release it. If you've mixed up GPL or AGPL code such that you can't release it you've violated the license for the hard work of others. You sound confused, to phrase it charitably.
Re: Willem Pinckaers on Akamai's flawed OpenSSL allocator patch
#79Earlier quoted context omitted.
Speaking as a security researcher at Akamai, I can say that tptacek is 100% correct here. We're absolutely better off for having received Willem's report, and I'm pretty sure we're all mature enough to tolerate the jabs that accompanied it. I didn't have any part in writing this allocator, but I was asked to do a code review prior to publication. I told Rich Salz that it would take me at least two days to do a thorou…
There's probably a middle ground here. If you'd taken the time to make sure the patch actually compiled, ran and attempted the things it was advertised to do before releasing it, I suspect problems with it would've been obvious sooner.
Sadly, the multiverse doesn't yet let me monitor its A/B tests.