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
