MIT Kerberos for Windows

[Jean-Yves Avenard]

Hi

On 2 October 2010 02:13, Jeffrey Altman <jaltman at secure-endpoints.com> wrote:
> The above SDK is built from the Heimdal source tree.  There is no
> benefit to building that source tree over the MIT KFW source tree if all
> you are attempting to obtain is a gssapi.lib to link against.  The
> approach you got working last night is sufficient for your needs.

It actually turned out no to be working as I expected. While
saslGSSAPI.dll isn't linked to gssapi.dll anymore, the subversion exe
itself is.

What I have started is something similar in effect to your SDK ; a
proxy library doing something for each GSS functions something like

OM_uint32 gss_display_status
(OM_uint32 *a1,		/* minor_status */
            OM_uint32 a2,			/* status_value */
            int a3,			/* status_type */
            gss_OID a4,			/* mech_type (used to be const) */
            OM_uint32 *a5,		/* message_context */
            gss_buffer_t a6		/* status_string */
           )
{
    HINSTANCE hinstLib;
    OM_uint32 (__cdecl *ProcAdd)(OM_uint32 *, OM_uint32 , int,
gss_OID, OM_uint32 *,gss_buffer_t );

    hinstLib = LoadLibrary(TEXT(GSSAPI_DLL));

    if (hinstLib != NULL)
    {
        ProcAdd = (MYPROC) GetProcAddress(hinstLib, "gss_display_status");

        if (NULL != ProcAdd)
        {
            return (ProcAdd) (a1, a2, a3, a4, a5, a6);
        }
        FreeLibrary(hinstLib);
    }
    return GSS_S_FAILURE;
}

So there's no need for any of the GSSAPI source code whatsoever, just
the header file.

SASL and Neon only uses 12 of the GSS functions, so it's not so bad ...

Jean-Yves