Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
RT-Send-CC:
X-RT-Original-Encoding: iso-8859-1
Content-Length: 896

Simo points out that it's possible to write password-verifying code 
using gss_acquire_cred_with_password() and 
gss_init/accept_sec_context to a locally controlled service, and the 
current semantics of gss_acquire_cred_with_password() are completely 
broken for that.

At this point I think it's probably best to revert to the Solaris 
behavior of gss_acquire_cred_with_password(), and make any existing 
applications change to use gss_store_cred() if they want.  We also 
need to fix gss_store_cred() as described in ticket #8010.

Unfortunately, applications won't have an easy way to tell which 
behavior they will get, until everyone upgrades away from old 
versions (and that's assuming Heimdal also makes the changes).  The 
best way to fix this is to deprecate gss_acquire_cred_with_password() 
in favor of a more general function, but that requires a non-trivial 
amount of design work.