Dovecot SASL GSSAPI regression with krb5 1.18

[Mantas Mikulėnas]

Hello,

I have a mostly normal Dovecot 2.3.10 configuration with SASL GSSAPI:

	auth_mechanisms = anonymous plain gssapi
	# auth_gssapi_hostname is unset
	auth_krb5_keytab = /etc/dovecot/dovecot.keytab
	auth_verbose = true

This used to work with MIT Kerberos version 1.17.1, and Dovecot would
automatically determine the system's FQDN and would find the principal
"imap/wolke.nullroute.eu.org at NULLROUTE.EU.ORG" in its keytab.

However, the principal search broke after upgrading to 1.18 -- now, each
authentication attempt reports:

	dovecot[1367034]: auth: gssapi(...): While acquiring service
credentials: Unspecified GSS failure.  Minor code may provide more
information
	dovecot[1367034]: auth: gssapi(...): While acquiring service
credentials: No key table entry found matching imap/.nullroute.eu.org@

I have tracked this down to commit 99635376 "Qualify short hostnames
when not using DNS". I'm still not entirely sure what is happening here,
but it seems to me that Dovecot tries to pass an empty hostname to
GSSAPI -- despite its docs saying that auth_gssapi_hostname should
default to gethostname() -- and Krb5 canonicalizes that empty string
resulting in a garbage domain name.

For now I can work around the issue in various ways: I could set
'qualify_shortname = ""' in krb5.conf to revert to old 1.17 behavior, or
I could set 'auth_gssapi_hostname' in Dovecot to *actually* hold the
system hostname or even the correct FQDN.

However, I'd much rather have everything work "by default" -- it did
work in previous versions, after all -- and it seems to me that the
check in k5_expand_hostname() should avoid canonicalization when `host`
is an empty string, too.

So would this be considered a bug in krb5, or is it an expected change
in behavior? (In addition to what I assume is a bug in Dovecot itself)

-- 
Mantas Mikulėnas