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.

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

>> I need access to that code via HTTP. Nothing else works at work but I
>> would be happy to try that. Results won't be available before next friday.
>
> Thanks! http://david.woodhou.se/openconnect-6.00.tar.gz

Test will follow!

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