On 10/27, Daniel Stenberg wrote:
> 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.

Could this be preceded by a graceful transition period, in which e.g. libcurl
prints a big warning? Or maybe it could be made optional at first (e.g. using a
configure flag). I don't know about other distributions, but Debian has a lot
of packages that build depends on libcurl, and testing all of them will surely
take a lot of time, so having this as optional at first will help testing all
the packages and at the same time it will avoid preventing updates of curl.

Also, is there going to be a SONAME bump too?

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;<inidehG ordnasselA>;eg;say~~reverse'

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