Revision fcdd2de1 added the K5_KEY_GSS_KRB5_ERROR_MESSAGE key, and
registered it in the gssapi library initialization routine, but
did not unregister it in the libary finalization routine.
When the library is unloaded and reloaded in the same process,
this leads to an assertion failure, since we check that
destructors_set[keynum] is zero (no destructor set) when registering
a key in util/support/threads.c.
Unregister the key on library cleanup to resolve the error.

ticket: 7353
target_version: 1.10.4
tags: pullup

Using the new internal JSON support to implement serialization and
unserialization of krb5 GSS credentials.

ticket: 7354

ticket: 7347 (new)

krb5_gss_export_name uses malloc to construct a gss_buffer_desc value,
and should use gssalloc_malloc instead.

ticket: 7233

Fix some GSSAPI buffer allocations which were missed in
800358b1790ef82710af0b6021c6ff2dca2b0de7: gss_export_sec_context,
gss_display_name, and IAKERB and SPNEGO token construction.

ticket: 7233 (new)
tags: pullup

Because the gssalloc macros are normally equivalent to malloc and free
on Unix, we cannot use the full test suite to find cases where we
allocate with malloc and free with gssalloc_free or vice versa.
Provide a way to test for this kind of bug (if only in a special build
configuration) by supporting a DEBUG_GSSALLOC symbol, which causes the
gssalloc wrappers to be deliberately incompatible with malloc and
free.

This function did not serve any useful purpose.  Remove it and the
special case it creates; move the only function it contained to the
main gss_mechanism structure where it belongs.  Note that the function
name is preserved so that loadable modules are not affected by this
change.