kdc "status" - string or number

[Simo Sorce]

On Fri, 05 Feb 2010 23:53:03 -0500
Greg Hudson <ghudson at mit.edu> wrote:

> On Wed, 2010-02-03 at 16:29 -0500, Zhanna Tsitkova wrote:
> > I suggest to make “status” an integer and use com_error tables to  
> > translate them into the meaningful strings when needed.
> 
> Taking a step back:
> 
> The fundamental problem is that there are two views of an AS or TGS
> error: the protocol error code, such as KDC_ERR_POLICY, which is
> limited to the set of RFC 4120 error codes, and the specific problem,
> like "renewable tickets requested but not allowed by the
> {client/server} principal".  Currently we use errcode (a
> krb5_error_code) to describe the former, and status (a string
> literal) to describe the latter. (Well, more or less.  If errcode is
> not one of error codes corresponding to RFC 4120 errors, we map it to
> KRB_ERR_GENERIC, and this happens in some cases.)
> 
> We could use krb5_set_error_message on the protocol error code to
> eliminate the need for the status string, but that assumes we still
> want the specific problem to be represented as a string.  That would
> be no more friendly to an audit system than the current design.
> 
> Zhanna's proposal is essentially to carry around two numeric error
> codes--one for the the protocol error code and one for the
> implementation-specific description of the problem.  To address Sam's
> concern, we could still use krb5_set_error_message on the KDC-internal
> error code to generate more complete descriptions of problems.
> 
> An alternative proposal would be to use KDC-internal error codes
> everywhere, and have a big function or table which maps them onto
> protocol errors.  That design would simplify the error-handling code
> within the KDC, at the expense of having a long-range correspondence
> between the set of error codes used in the KDC (and subsidiary
> libraries) and the protocol error code map.
> 
> > 2.    Keeping English strings in the fewer places simplifies  
> > localization of the error messages/logs
> 
> We don't have to collect all of the English strings together to do
> localization; the usual practice in open source projects is to use
> xgettext to extract English strings from source files into message
> catalogs.
> 
> The audit system justification is sufficient to make some kind of
> change, though.

These messages are only useful for an audience that is intimate with
kerberos, it is entirely acceptable to think that audience is also
comfortable reading error messages in English. The problem of
translating is that otherwise you can get back errors in languages most
do not understand and that would make it very difficult to help this
people should they ask help from others that speak only English.

Also, when dealing with networks transmitted errors you have to
remember that 2 machines may be configured with different languages.
The server may be configured with English, and the client with
say German. That would mean the server need to have translation for all
clients and keep status to know what translation to use for every
different client. Should the KDC ever become multi-thread or otherwise
become able to perform multiple operations at the same time you'd have
to be very careful to change the internal translation context.

Also this would require every plugin writer to get access to the
language and provide translations of every error message.

All this considered I think it would be best if text error messages are
preceded by a small unique code that is used as a key on the *client*
side to translate those few messages that people may want to display in
a UI to common users.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York