4 ms·

Maddening isn't it?

tptacek 13y ago
I am totally, completely in the dark as to which coding errors (there have been several in the past few months) attach to which CVEs and which versions, and about when these vulnerabilities were reported to the project and when they were subsequently disclosed. I can't be the only one confused, and I do wonder whether that confusion is strategic. Pointing this out would be be gratuitous, except that Cryptocat's project leader has very high standards when it comes to the disclosure behavior of that project's competitors: https://github.com/SilentCircle/silent-phone-base/issues/5 https://github.com/SilentCircle/silent-phone-base/issues/5 (Cryptocat is "kaepora" in that thread; the context there is that Mark Dowd had reviewed ZRTPCPP, an open source implementation of the ZRTP protocol that Silent Circle funds and relies on, and found several memory corruption vulnerabilities. Mark had gone public with those vulnerabilities quickly as a result of a miscommunication with the Silent Circle team, but then redacted his disclosure and agreed to embargo the findings while Silent Circle coordinated fixes with all of the Silent Circle competitors that relied on that library; what you see in that thread is, apparently, the lead developer of Cryptocat, which doesn't use ZRTPCPP, repeatedly criticizing Silent Circle's handling of the incident.) The project should meet the standards that it has loudly set for others, and I don't think it has. I'd be happy to be corrected on this.
- oinksoft 13y ago
  Anyone saying, "oh, this is just the little guy trying so hard, take it easy on him" really ought to read the thread you linked. The author of CryptoCat's demeanor is surprisingly aggressive in his comments.
- DanBC 13y ago
  [edited to keep this thread constructive]
  - tptacek 13y ago
    My concern is substantive: In the process of handling an embargoed disclosure, Silent Circle groomed (perhaps aggressively) a Github pull request thread. Handling a coordinated disclosure on a Github pull request is tricky under the best of circumstances, but the Silent Circle team was dealing with an unplanned partial disclosure and was, with Dowd's cooperation, trying to get the genie back into the bottle long enough for (from what I can tell) their competitors to get patched. This was, as is evident from the thread, a problem for Cryptocat's uninvolved, un-implicated lead developer. Meanwhile: I cannot immediately tell from the record which of the independently discovered vulnerabilities in Cryptocat correspond to which CVEs or which advisories and which severity descriptions. The problem isn't one of demeanor; it's that I can't tell what's going on with this project. Does this sound fiddly? Let's make it more concrete: did an exploitable vulnerability get reported to the Cryptocat project, mitigated in a public Github commit, and sit there for months without any acknowledgement from the project? Cryptocat's project leader is an HN commenter, and if this confusion is my own doing --- totally possible --- I'd be happy for some clarification; not about Silent Circle, but on how someone would get a record of what vulnerabilities were disclosed in Cryptocat, when, and what the timeline was for each from discovery to public disclosure. It's plausible that there's a clear record somewhere and I just missed it.
zaroth 13y ago
It's so bad I want to put on my tin foil hat and believe the NSA made them do it. How do you go back to the same mission-critical single line of code again, and AGAIN and keep getting it wrong? Any change to that line of code raises extreme red flags. As a developer, if you're making a change to that line after it shipped, you're in complete "wow I fucked up bad" mode. Instead it looks like they're just changing it randomly, month after month, like it's some inconsequential debug flag. Really, this just blows my mind.

Maddening isn't it?

I am totally, completely in the dark as to which coding errors (there have been several in the past few months) attach to which CVEs and which versions, and about when these vulnerabilities were reported to the project and when they were subsequently disclosed. I can't be the only one confused, and I do wonder whether that confusion is strategic. Pointing this out would be be gratuitous, except that Cryptocat's project leader has very high standards when it comes to the disclosure behavior of that project's competitors: https://github.com/SilentCircle/silent-phone-base/issues/5 https://github.com/SilentCircle/silent-phone-base/issues/5 (Cryptocat is "kaepora" in that thread; the context there is that Mark Dowd had reviewed ZRTPCPP, an open source implementation of the ZRTP protocol that Silent Circle funds and relies on, and found several memory corruption vulnerabilities. Mark had gone public with those vulnerabilities quickly as a result of a miscommunication with the Silent Circle team, but then redacted his disclosure and agreed to embargo the findings while Silent Circle coordinated fixes with all of the Silent Circle competitors that relied on that library; what you see in that thread is, apparently, the lead developer of Cryptocat, which doesn't use ZRTPCPP, repeatedly criticizing Silent Circle's handling of the incident.) The project should meet the standards that it has loudly set for others, and I don't think it has. I'd be happy to be corrected on this.

oinksoft 13y ago
Anyone saying, "oh, this is just the little guy trying so hard, take it easy on him" really ought to read the thread you linked. The author of CryptoCat's demeanor is surprisingly aggressive in his comments.
DanBC 13y ago
[edited to keep this thread constructive]
- tptacek 13y ago
  My concern is substantive: In the process of handling an embargoed disclosure, Silent Circle groomed (perhaps aggressively) a Github pull request thread. Handling a coordinated disclosure on a Github pull request is tricky under the best of circumstances, but the Silent Circle team was dealing with an unplanned partial disclosure and was, with Dowd's cooperation, trying to get the genie back into the bottle long enough for (from what I can tell) their competitors to get patched. This was, as is evident from the thread, a problem for Cryptocat's uninvolved, un-implicated lead developer. Meanwhile: I cannot immediately tell from the record which of the independently discovered vulnerabilities in Cryptocat correspond to which CVEs or which advisories and which severity descriptions. The problem isn't one of demeanor; it's that I can't tell what's going on with this project. Does this sound fiddly? Let's make it more concrete: did an exploitable vulnerability get reported to the Cryptocat project, mitigated in a public Github commit, and sit there for months without any acknowledgement from the project? Cryptocat's project leader is an HN commenter, and if this confusion is my own doing --- totally possible --- I'd be happy for some clarification; not about Silent Circle, but on how someone would get a record of what vulnerabilities were disclosed in Cryptocat, when, and what the timeline was for each from discovery to public disclosure. It's plausible that there's a clear record somewhere and I just missed it.

zaroth 13y ago

It's so bad I want to put on my tin foil hat and believe the NSA made them do it. How do you go back to the same mission-critical single line of code again, and AGAIN and keep getting it wrong? Any change to that line of code raises extreme red flags. As a developer, if you're making a change to that line after it shipped, you're in complete "wow I fucked up bad" mode. Instead it looks like they're just changing it randomly, month after month, like it's some inconsequential debug flag. Really, this just blows my mind.