On 4 Mar 2008, at 20:43, Will Fiveash wrote: > On Tue, Mar 04, 2008 at 08:32:18PM +0100, Mark Phalan wrote: >> >> On 4 Mar 2008, at 19:35, Will Fiveash wrote: >> >>> 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. >> >> If thats true then we should change the message for >> KRB5_BAD_ENCTYPE. Maybe >> file a CR? > > Okay, will do later. > >>> 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). >> >> Agreed, that would be nicer. Care to suggest something? > > Errors from the other end could always start with: > > Error from remote system:
I can change this error message to be as follows: "kadmin: Errors from remote system: Bad encryption type while changing k's key "kadmin: Encryption types requested: aes256-cts-hmac-sha1-96 (18), ..." Sound ok? I think its a good idea in general and something we should think about doing more comprehensively. -Mark