4 ms·
I 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
by stouset 10y ago
I 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.