MIT Kerberos using invalid in-memory credential cache

Vipul Mehta vipulmehta.1989 at
Thu Jan 7 03:11:03 EST 2021

I tried the fix but it didn't work. I observed there are some other issues
w.r.t. mechanism type from curl and would like to understand behavior
before further analysis.

1) How is default credential picked up when GSS_C_NO_CREDENTIAL is
specified in gss_init_sec_context() ? How is in-memory credential cache
used here ?
2) If the GSS credential passed to  gss_init_sec_context() does not match
the specified mechanism type then  GSS_C_NO_CREDENTIAL is the value
returned from gssint_get_mechanism_cred().  Why it does not simply fail
here as client didn't pass matching oid and cred ?

On Wed, Dec 30, 2020 at 10:43 PM Greg Hudson <ghudson at> wrote:

> On 12/29/20 7:21 AM, Vipul Mehta wrote:
> > I see that some fix has been done in newer version :
> >
> >
> > Will it help ? How to debug this issue further in our service ?
> It might.  One of the bugs fixed in that commit is that two simultaneous
> references to the same memory cache would cause one of the references to
> become a dangling pointer when the other is destroyed.  I'm not sure how
> upgrading curl would lead to that scenario, though.
> If you choose to backport this commit, note that it contained a bug,
> described here:


More information about the krbdev mailing list