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: or something along those lines. -- Will Fiveash Sun Microsystems Inc. Austin, TX, USA (TZ=CST6CDT)
