cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: krb4 and CURLOPT_KRBLEVEL

From: Dan Fandrich <dan_at_coneharvesters.com>
Date: Sat, 15 Nov 2014 21:10:42 +0100

On Sat, Nov 15, 2014 at 05:57:19PM +0000, Steve Holme wrote:
> On Sat, 15 Nov 2014, Dan Fandrich wrote:
>
> > > I have prepared a patch to remove this (see attached), however, from
> > > reading the libcurl code (security.c) and associated comments it seems
> > > more of a generic "Kerberos" option. Does anyone know if it is used
> > > for Kerberos 5 at all?
> >
> > I don't know the answer to that question, but if someone has a script with
> > "--krb 5" said script will fail if this patch goes through. You may want to
> > support the option and just print a warning (even if it does nothing else) if
> > it's ever used.
>
> From a curl command line point of view my patch really doesn't do anything different as the current code checks for the presence of CURL_VERSION_KERBEROS4 which won't be there (when >= 7.33.0 ).

The difference is curl aborting because of an unknown option (with the patch),
and curl ignoring the option and continuing anyway (without the patch).

> I don't know much about FTP but from reading the code, an application who uses libcurl, could perform curl_easy_setopt(CURLOPT_KRBLEVEL, 4); will cause a "PROT P" (for PRIVATE) command to be sent to the server- Do you know if this applicable to both other authentication mechanisms (inc. krb5) in FTP?

PROT is used for generic TLS encryption and has nothing to do with Kerberos
directly, as I understand it (maybe it has some subtle semantic difference
there).

> If it isn't then I think we should go ahead with my patch and then deprecate
> the option in libcurl.
>
> If, on the other hand, it is applicable to krb5 and others then we should fix the curl command line tool so that "curlinfo->features & CURL_VERSION_KERBEROS4" either a) becomes "curlinfo->features & CURL_VERSION_KERBEROS5" with the possibility of other mechanisms being added to the check in the future or b) is removed.
>
> Alternatively we just leave it as it is ;-)
>
> ...but then we have an inconsistency between what libcurl can do and what the command line version of curl can do :(

>>> Dan
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-11-15