On Thu, 25 Oct 2012, Mark Tully wrote:

>> 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.

It struck me that there's a good argument why not allow 1 at all:

If we allow 1 or 2 having the same effect in upcoming releases, which would be
sead simple, it would of course lead to programs using 1 or TRUE to get this
effect. When running that program on an older libcurl, it will run unsecurely.
So instead of fixing the problem, we risk actually expanding the problem if
people write code that runs on multiple libcurl versions - something which is
known to happen quite a lot.

I thus suggest we simply ban 1 as a value in an upcoming release. This will
fource users to use 2 instead and when copying such code back to older
libcurl-using code that will improve the code running there as well!

See my attached patch that does exactly this. As this *will* cause one or two
legitimate users get an error I'm very interested in further feedback.

The PHP guys discussed doing the change in there end, in this discussion:

   http://thread.gmane.org/gmane.comp.php.devel/76531/focus=76546

... but I saw nobody agreeing to that.

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

I can't think of any obvious ones, no...

-- 
  / daniel.haxx.se

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html