Description of problem: I'm the maintainer for pidgin-sipe. I just upgraded from Fedora 18 to Fedora 19 Beta and the following piece of code from pidgin-sipe now fails if "kinit" has not been executed first. /* Acquire default user credentials */ ret = gss_acquire_cred(&minor, GSS_C_NO_NAME, GSS_C_INDEFINITE, GSS_C_NO_OID_SET, GSS_C_INITIATE, &credentials, NULL, NULL); pidgin-sipe code relies on gss_acquire_cred() to work and falls back to acquiring a TGT (with provided user name & password) if the next step [gss_init_sec_context()] fails. Version-Release number of selected component (if applicable): krb5-libs-1.11.2-10.fc19.x86_64 How reproducible: Always Steps to Reproduce: 1. pidgin & pidgin-sipe with account that supports Kerberos authentication 2. DO NOT run kinit (or use kdestroy to remove the existing tickets) 3. go online with the account Actual results: (09:50:23) sipe: sip_sec_acquire_cred__krb5: started (09:50:23) sipe: sip_sec_krb5: GSS-API error in gss_acquire_cred (GSS): Unspecified GSS failure. Minor code may provide more information (09:50:23) sipe: sip_sec_krb5: GSS-API error in gss_acquire_cred (Mech): No Kerberos credentials available (09:50:23) sipe: sip_sec_krb5_acquire_credentials: failed to acquire credentials (ret=851968) Expected results: No failure Additional info: I've already fixed the missing /run/user/0 directory issue from bug #961235. Without that even kinit wouldn't work at all on my machine. F18 has krb5 1.10.x so I'm guessing the behaviour has changed. I'm no krb5 expert. It could be that pidgin-sipe code does it wrong, but this approach for non-kinit use case has always worked until now. If the approach is wrong can an krb5 expert point me to the information where & why this was change for krb5 1.11.x?
Why do you think this call should succeed if you have no crdentials ? You are trying to acquire credentials, but you have none, and gss_acquire_cred is failing with an error saying you have no credentials, which is the truth as far as I understand. In 1.10, gss_acquire_cred often does not immediately try to acquire credentials, but defers the operation to the time when gss_init_sec_context() is executed. All that said, given you are not passing any specific name or option to gss_acquire_cred() you should probably simply remove the call, and use gss_init_sec_context() directly. To me this looks a a NOTABUG, unless Nalin spots something I missed.
I didn't write the original code. As the code flow always worked until now, I never suspected that the gss_acquire_cred() call was pointless. I removed it from pidgin-sipe: http://repo.or.cz/w/siplcs.git/commitdiff/d19a69fe6afacf7b9fc756e077c70cb3092d1df3 I verified that this works on krb5 1.8.x, 1.10.x & 1.11.x. Thanks for pointing out the problem. Closing as NOTABUG
Wait a minute. What if I have to use gss_acquire_cred() just so that I can use gss_set_neg_mechs() for SPNEGO? Surely I might have good reason to use GSS_C_NO_NAME then? Or how *else* do I set the mechanisms for it to use?
Yes David, if you have a good reason to use gss_acquire_cred() by all means use it. Just do not expect it to always immediately indicate whether you have valid credntials or not, you always have to go all the way to gss_init_sec_context() to find that out. This is true now as was before, a user can always call kdestroy when your code is doing a reconnection attempt right between your call to gss_acquire_cred() and gss_init_sec_coontext()
As long as it doesn't *fail*, for SPNEGO, just because I don't have Kerberos creds. I might have creds for one of the *other* mechanisms that I expect SPNEGO to fall back to...