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
