>> As to what we can do to make cURL even better (in order to protect
>> unprofessional users that don't know what they are doing), We could make '1'
>> to act as '2' (verify peer identity), and add a special magic value (i.e.
>> 27934) that will act as todays '1' (check for CN existence but don't verify
>> it).
>>
>> I think most of users do not intend to use '1' in the unsecure way, so most
>> of them will be happy with this change of behavior.
>
> Yes, I agree with this and I believe it could be an acceptable way forward. I
> don't think 1 is used on purpose very much so it wouldn't hurt a lot.

FWIW I think this is a sensible compromise.

Additionally, you could revoke the CURL_SSL_VERIFY_HOST value from the headers, and maybe replace it with two explicit options, one to enable SSL verification and one to turn off full checking. Then anyone who tries to compile against the new version would be forced to fix their code as they intended it. However, not sure it's worth causing the pain across all the code bases that use CURL, considering most people would fix in the same way your 'silent' fix does anyway.

Are there any other options where TRUE / 1 are bad values? Perhaps there are similar fixes to be pre-emptively made elsewhere?

Cheers,

        Mark

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