Luke Howard

Agree with @nicowilliams (I wrote pam_ldap many years ago).

This will likely be a source-breaking change for plugins that import Heimdal headers and implement the GSS-API, such as Moonshot.

We could insulate by including a private copy of the header in mech_eap but, need to be careful as there are some platform-specific things like structure packing on macOS. I’d...

> Or we could have a macro that makes all the gss_const_* types not const. > I think I already did that in the current code. It’s dealing with mixed...

Yeah it’s probably the best option. > On 6 Apr 2019, at 22:12, Nico Williams wrote: > > I mean, PuTTY and the OpenJDK include their own private copies of...

@nicowilliams wants to change it yet again to add more const-ness, which is correct but would be another source breaking change for building mech_eap against Heimdal (unless of course we...

It's not Mac-specific though, it's any platform that uses Heimdal (does Debian use it?). I think the right answer is to actually have a private gssapi.h in mech_eap. But this...

We already have one in mech_eap, problem is that to deal with different Heimdal versions we'd need to have two macros. Then it gets ugly quickly.

Actually that's not correct, we don't have a macro. Currently it is like: ```c OM_uint32 GSSAPI_CALLCONV gss_accept_sec_context(OM_uint32 *minor, gss_ctx_id_t *context_handle, #ifdef HAVE_HEIMDAL_VERSION gss_const_cred_id_t cred, #else gss_cred_id_t cred, #endif gss_buffer_t input_token,...

but yes, probably want to avoid something like `GSS_MAYBE_CONST`...