On Thu, Aug 15, 2013 at 11:50:14AM -0400, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE-----
There was duplicated code in cc_file_check_existing() and in
cc_dir_check_existing(). I pulled them into the same function.
There are two changes made to the original code here:
1) Fixes a use-after-free bug in cc_file_check_existing(). In the
original code, we called krb5_free_context() and then used that
context immediately after that in krb5_cc_close(). This patch
corrects the ordering
2) The krb5_cc_resolve() call handles KRB5_FCC_NOFILE for all
cache types. Previously, this was only handled for DIR caches.
This second part I need someone with Kerberos knowledge to verify. Is
there a risk of receiving this error for the FILE or KEYRING types,
and if so is this handling still acceptable or should they be
I think it is save for two reasons. First, after a quick look at the MIT
source code I think that currently FILE and KEYRING do not return
KRB5_FCC_NOFILE when calling krb5_cc_resolve(). And even if this is
changed in some other version the current code will return an error and
the authentication will fail. Your version will assume that the ticket
in not valid and try to get a new one, which looks more friendly to the
user than just failing.
I'll try to run some tests later today.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----