5 ms·
> The handling of this issue by the Go maintainers was exemplary. They had no security problem but accepted that so many people misusing the library was a secur
by stouset 10y ago
> The handling of this issue by the Go maintainers was exemplary. They had no security problem but accepted that so many people misusing the library was a security problem and that they could do something about this.
I disagree with the author here. A poorly-designed API that encourages rampant insecure misuse is a security vulnerability.
Documentation is not an excuse here.
- jerf 10y agoA poorly-designed API, which they fixed, despite backwards incompatibility. If you're going to insist that everybody gets everything security-related exactly right the first time, well, you may be morally in the right but you're signing up for a lot of disappointment.
- 0xdeadbeefbabe 10y agoI hope signing up for disappointment isn't the real goal.
- stouset 10y agoI never said they had to get it right from the start, and I'm happy they fixed the API. My only contention was the author's (incorrect, in my view) distinction between a security vulnerability and an API design that encourages security vulnerabilities. The latter are worse in my opinion, because they're harder to fix.
- emmelaich 10y agoYou're applying a rigid idea of sharp definition of what constitutes a security vulnerability. I'm sure this attitude is behind the 90% useless "security reports" that they receive.
- stouset 10y agoThere is no sharp definition here. The relative ease or difficulty of using an API in secure ways is unavoidably imprecise with vague boundaries. It is a continuum, not a binary value. That said, an issue like the one reported is inarguably on the wrong side of that boundary, both conceptually (not requiring host key verification by default) or empirically (by the data collected by the reporter). Thanks, though, for your unnecessary, gratuitous, and frankly absurd editorialization. API design is critically important to security whether or not you believe it to be — we've learned this the hard way through decades of treating keys and IVs as "stringly typed", as overwhelming numbers of developers use `rand` to generate keys and use hardcoded IVs. An API design that encourages misuse will be misused, and the onus to improve the default situation should be on the author of such APIs.
- emmelaich 10y agoYou italicised the `is`. Sounds pretty sharp to me.
- merb 10y agowell I upvoted you but I can't fully agree. While you are write that a poorly-designed API that will make my code insecure is a bad design, however sometimes you just want the insecure design. Something like making a insecure web service call to a legacy device that mishandles every secure request. However I think it should at least than give a compiler warning/or a runtime warning. Also changing a API of a stdlib is probably not a cool way. I like Java that they don't change things so fast, however in Java they rate of change is too slow, after deprecating something it should be removed some day (java never did), however in go/rust the rate of change is way too much. (and I really like rust) well both have a different release procedure than java, but still when I develop something I really hope that my API keeps the same at least 3 years or more.
- stouset 10y agoHaving a way to "break the seal" and void the warranty is fine, but it should require conscious decision making. Designing APIs such that the easiest, most straightforward use of the API voids any security guarantees just results in situations like the one that happened here, where everyone gets it wrong.