This bug only happens when krb5_get_init_creds_password falls back to
the master KDC, causing krb5_get_as_key_password to be called a second
time with the password already set to an empty value.
This bug manifests differently in versions prior to 1.11:
$ kinit user
Password for user@KRBTEST.COM: [user hits return]
Password for user@KRBTEST.COM:
kinit: Cannot read password while getting initial credentials
The bug is already fixed for real on trunk by #7642, but I think that's
too expansive a change to backport. But it is probably worth fixing the
assertion failure in 1.11 (reverting to the old misbehavior) by simply
removing the assert(); I've attached a patch.
diff --git a/src/lib/krb5/krb/gic_pwd.c b/src/lib/krb5/krb/gic_pwd.c
index 30da8c9..95379c0 100644
--- a/src/lib/krb5/krb/gic_pwd.c
+++ b/src/lib/krb5/krb/gic_pwd.c
@@ -26,7 +26,6 @@ krb5_get_as_key_password(krb5_context context,
const char *rpass;
password = (krb5_data *) gak_data;
- assert(password->length > 0);
/* If we need to get the AS key via the responder, ask for it. */
if (as_key == NULL) {