Am 2014-07-11 20:41, schrieb David Woodhouse:
> On Fri, 2014-07-11 at 20:09 +0200, Michael Osipov wrote:
>> Am 2014-07-11 19:41, schrieb David Woodhouse:
>>> On Fri, 2014-07-11 at 19:17 +0200, Michael Osipov wrote:
>>>> I would implement a fallback but provide two options where one should be
>>>> picked sticked to it:
>>>>
>>>> 1. Discover SPNEGO capability at compile time with autoconf. GSS-API
>>>> provides this option:
>>>>
>>>> OM_uint32 major, minor;
>>>> gss_OID_set mech_set;
>>>> major = gss_indicate_mechs(&minor, &mech_set);
>>>>
>>>> and then you can test the for set members with a default function.
>>>
>>> That doesn't work if you're cross-compiling. It's best to avoid tests
>>> that you have to *run* at configure time, if we can
>>
>> hmm...configure.ac *does* already some compile checks. E.g.,
>> "[if you have an old MIT Kerberos version, lacking
>> GSS_C_NT_HOSTBASED_SERVICE])"
>>
>> But if this is a problem, we can omit this compile time check.
>
> Compile checks are fine. It's AC_TRY_RUN which is an abomination and
> should be avoided at all costs. Unless I misunderstood, your suggestion
> was that we not only *compile* something for the target, but also try to
> *run* it. Which isn't possible if we're cross-compiling.

Can you explain why AC_TRY_RUN is bad? I haven't never written a
complete configure.ac script but only using it.

You understood me correctly, compile *and* run. Then, cross-compilation
is not possible of course.

>>>> 2. Use SPNEGO by default and if the GSS-API impl does not support SPNEGO
>>>> it will fail with an GSS error.
>>>>
>>>> Give that this is a corner case and should apply only to a fraction of
>>>> users, I would go for option 2, e.g., your implementation.
>>>
>>> Or we could have the known broken cases hard-coded, and allow
>>> --without-spnego at configure time rather than attempting a runtime
>>> check?
>>
>> I do not think that this is necessary. I would rather rely on
>>
>> 1) upgrading GSS-API,
>> 2) not fiddle with a small amount of ancient versions, and
>> 3) the gss_display_status which indicates that this mech is not available.
>
> Yeah, fair enough. So you're saying it's not necessary to do *anything*,
> and we just rely on people having a not-completely-insane implementation
> of GSSAPI? I'm happy enough with that, and it requires no extra work :)

Yes

> So what *do* we want to do on top of the patch set I posted? Just add
> support for '{Proxy,WWW}-Authenticate: Kerberos'?

I would rather do that after this patch has been tested, approved and
committed. This is the safest way to implement that improvement on top.
I don't like to fix two things in one big patch. It ends up in a mess.

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