6 ms·

The tone of his post is rather unfortunate. Still, he raises good points, even if they are put in an unnecessarily aggressive manner.

gojomo 13y ago
How would a less-aggressive tone be better at delivering the necessary info to Akamai and its customers?
- deleted 13y ago
  [deleted]
  - makomk 13y ago
    The fact the code is badly written and wouldn't run isn't even the biggest problem with it though - a bigger issue is that the author didn't appear to realise there were copies of the key they'd missed that weren't protected. They very likely made the same mistake with their production systems and their analysis of those production systems.
davidmat 13y ago
I don't find it aggressive, it seems more like Dutch directness to me. As an inhabitant of a neighbouring country, I must say it's an acquired taste ;)
tptacek 13y ago
I disagree. The post is written bluntly, but it argues with factual assertions, not with emotional appeals. I don't think criticism of its tone is warranted or really all that appropriate.
- UnoriginalGuy 13y ago
  This: > Perhaps Akamai is not actually running this version in production, but another 'super secure' allocator. In either case they should not be sending out non-functional, bug ridden patches to the OpenSSL community, while claiming they protected Akamai against the Heartbleed attack. Andy Ellis, CSO of Akamai, said on Twitter that the 'secure' allocator was written 13 years ago. I'm happy to provide the results of my 15 minute security review, since it is so overdue. (To be fair, I found the issue in minutes, but confirmation took longer.) Comes across quite passive aggressive indeed. The tone is otherwise fine, except that paragraph which is just one giant jab at Akamai. I guess it is true what they say: No good deed goes unpunished. I'm sure Akamai has learned their lesson and will keep all future patches private to avoid public criticism and ridicule. But on the positive side at least we all know how smart Willem is, which I'm sure was the real point anyway.
  - deleted 13y ago
    [deleted]
  - tptacek 13y ago
    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.
    - babs474 13y ago
      tptacek, we all want to hear Willem Pinckaers' take, it is really good stuff. I also want to hear ideas from Akamai, even if they aren't perfect. Perhaps they can lead to good things. Unfortunately Pinckaers' commentary is a little bit too hostile and calls for Akamai to cease sharing ideas[1]. I'm sure Akamai's developers are "adult" enough, as you say, to handle it. However there is a trope in software development community that if you share something, you should be fine with being open to no holds barred attacks. Wouldn't the more "adult" behavior be to criticize in a more professional tone that is open to refinement of ideas and could spark further collaboration? I'd like to see this type of communication more in the software world, I think it would encourage more participation. [1]"they should not be sending out non-functional, bug ridden patches to the OpenSSL community"
      - Pacabel 13y ago
        I think there's a difference between sharing ideas and sharing code. An idea or concept on its own can't really do much, at least until it's put into practice somehow. The potential for harm is quite minimal, if it even exists. Code, on the other hand, can often be directly used with relative ease by people who may not fully understand the possible implications of using such code. The potential for harm exists, and could be significant. In the context of security, it's important to avoid potentially-harmful code wherever possible. If somebody has concerns about some code, regardless of who wrote it, it is best to express those concerns in a very blunt and direct manner. Security is just not something to fool around with. The hard questions and painful facts should be out in the open, especially when code is involved and capable of being used. It's just not the time or place for pussyfooting around.
- binarycrusader 13y ago
  Empathy is a core engineering value. If not exercised, people will unsurprisingly often ignore what you have to say. It's possible to be correct and helpful without saying unkind things.

gojomo 13y ago

How would a less-aggressive tone be better at delivering the necessary info to Akamai and its customers?

deleted 13y ago
[deleted]
- makomk 13y ago
  The fact the code is badly written and wouldn't run isn't even the biggest problem with it though - a bigger issue is that the author didn't appear to realise there were copies of the key they'd missed that weren't protected. They very likely made the same mistake with their production systems and their analysis of those production systems.

davidmat 13y ago

I don't find it aggressive, it seems more like Dutch directness to me. As an inhabitant of a neighbouring country, I must say it's an acquired taste ;)

tptacek 13y ago

I disagree. The post is written bluntly, but it argues with factual assertions, not with emotional appeals. I don't think criticism of its tone is warranted or really all that appropriate.

UnoriginalGuy 13y ago
This: > Perhaps Akamai is not actually running this version in production, but another 'super secure' allocator. In either case they should not be sending out non-functional, bug ridden patches to the OpenSSL community, while claiming they protected Akamai against the Heartbleed attack. Andy Ellis, CSO of Akamai, said on Twitter that the 'secure' allocator was written 13 years ago. I'm happy to provide the results of my 15 minute security review, since it is so overdue. (To be fair, I found the issue in minutes, but confirmation took longer.) Comes across quite passive aggressive indeed. The tone is otherwise fine, except that paragraph which is just one giant jab at Akamai. I guess it is true what they say: No good deed goes unpunished. I'm sure Akamai has learned their lesson and will keep all future patches private to avoid public criticism and ridicule. But on the positive side at least we all know how smart Willem is, which I'm sure was the real point anyway.
- deleted 13y ago
  [deleted]
- tptacek 13y ago
  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.
  - babs474 13y ago
    tptacek, we all want to hear Willem Pinckaers' take, it is really good stuff. I also want to hear ideas from Akamai, even if they aren't perfect. Perhaps they can lead to good things. Unfortunately Pinckaers' commentary is a little bit too hostile and calls for Akamai to cease sharing ideas[1]. I'm sure Akamai's developers are "adult" enough, as you say, to handle it. However there is a trope in software development community that if you share something, you should be fine with being open to no holds barred attacks. Wouldn't the more "adult" behavior be to criticize in a more professional tone that is open to refinement of ideas and could spark further collaboration? I'd like to see this type of communication more in the software world, I think it would encourage more participation. [1]"they should not be sending out non-functional, bug ridden patches to the OpenSSL community"
    - Pacabel 13y ago
      I think there's a difference between sharing ideas and sharing code. An idea or concept on its own can't really do much, at least until it's put into practice somehow. The potential for harm is quite minimal, if it even exists. Code, on the other hand, can often be directly used with relative ease by people who may not fully understand the possible implications of using such code. The potential for harm exists, and could be significant. In the context of security, it's important to avoid potentially-harmful code wherever possible. If somebody has concerns about some code, regardless of who wrote it, it is best to express those concerns in a very blunt and direct manner. Security is just not something to fool around with. The hard questions and painful facts should be out in the open, especially when code is involved and capable of being used. It's just not the time or place for pussyfooting around.
binarycrusader 13y ago
Empathy is a core engineering value. If not exercised, people will unsurprisingly often ignore what you have to say. It's possible to be correct and helpful without saying unkind things.