On Oct 29, 2012, at 3:33 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:

> Yes, that is what I'm suggesting. 0 or 2. With 1 then getting treated as illegal which internally will cause it to equal 2. (Within libcurl the value becomes a plain simple boolean though.)

I'm fine with getting rid of option 1. Yes, it will break maybe 1% of products out there that relied on 1 meaning allow any common name. But I think security fixes, even for fixes like these that are caused by misuse of the API by a few apps, have to be inconvenient in the short term to fix problems in the long term. I remember when the renegotiation hole was found in SSL/TLS a few years ago, and Apple pushed out a security update that disabled renegotiation being on by default in their OpenSSL library. Renegotiation wasn't a particularly useful feature, so nothing happened in the vast majority of apps that used Apple's OpenSSL, and for the tiny handful of apps that relied on this feature, they just fixed their code in a later release because they were forced to make the change, and life went on.

The ideal way of dealing with this would be to allow the buggy behavior if the app was linked against an older version of the library, which you can't really do in a cross-platform library since not every platform uses the same ABI.

Nick Zitzmann
<http://www.chronosnet.com/>

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2012-10-29