On Tue, Mar 04, 2008 at 07:07:01PM +0100, Mark Phalan wrote: > > On Tue, 2008-03-04 at 11:48 -0600, Will Fiveash wrote: > > On Tue, Mar 04, 2008 at 03:01:04PM +0100, Mark Phalan wrote: > > > > > > > > > The output now looks like: > > > > > > zup# ./kadmin -p mark/admin -q "ktadd -k /tmp/t t" > > > Authenticating as principal mark/admin with password. > > > Password for mark/admin at ACME.COM: > > > kadmin: Bad encryption type while changing t's key > > > kadmin: Encryption types requested: aes256-cts-hmac-sha1-96 (18), > > > aes128-cts-hmac-sha1-96 (17), des3-cbc-sha1 (16), arcfour-hmac (23), > > > des-cbc-md5 (3), des-cbc-crc (1) > > > zup# > > > > Better but how about: > > > > kadmin: Unknown encryption type while changing <princ>'s key > > kadmin: Encryption types requested: aes256-cts-hmac-sha1-96 (18), ... > > The "Bad enctyption type" string is the standard error-string associated > with KRB5_BAD_ENCTYPE (see krb5_err.c:587). It may be that > KRB5_BAD_ENCTYPE represents more than just: "I can't find the enc-type > requested". I'd rather leave it printing the more general error message.
I see your point but I also see that when browsing through the code with cscope that every place returning KRB5_BAD_ENCTYPE is doing so because the enctype is not known. I think stating that an enctype is unknown is more useful than stating it is "bad". But this is a nit. Another point regarding the usefulness of error messages is that it would be good, when possible to do so unambiguously, to state that the error is originating on the server if that's the case. For example when a user does a ktadd -e <some enctype> it's possible that the enctype is not known by kadmin or it could be that it is unknown by kadmind. Some indication as to which is the case would be nice (if possible). -- Will Fiveash Sun Microsystems Inc. Austin, TX, USA (TZ=CST6CDT)
