String attributes feature (project review)

[Greg Hudson]

On Mon, 2011-09-19 at 23:55 -0400, Dmitri Pal wrote:
> It seems that interface assumes that keys are unique. [...]
> I assume "set" acts as add if string does not yet exist, right?
> Is unset accomplished using NULL value for value? Will it delete the key?

Yes, yes, and yes.  I've made notes in the project page.

> Any expectations about sort order for the keys in the list?

The implementation I have happens to preserve insertion order, but
that's not guaranteed.

> What kinds of errors are returned?

krb5_dbe_set_string can return a new error code KRB5_KDB_STRINGS_TOOLONG
if the attributes won't fit in a tl-data value (64K).  Other than that
there are no special errors (other than ENOMEM or EINVAL).

Sam wrote:
> us-ascii or no-nulls-binary makes more sense for keys than Unicode.
> If you use Unicode I'd expect a normalization-insensitive comparison.

Since we aren't doing any UTF-8 processing on the keys or values in the
code, I changed the project page to refer to keys and values as C
strings.  Basically, 0 bytes aren't allowed, keys are compared using
strcmp(), and keys and values are entered and displayed without any
processing by the kadmin client.  Pretty much this means the use of
non-ASCII characters is a bad idea, unless the world gets to a point
where we can assume a UTF-8 character set in every terminal.

Simo wrote:
> I would say that a vendor prefix makes for a better name space

I don't think of KDC plugins as necessarily having a "vendor".  The OTP
plugin is written by Linus for NORDUnet and might at some point be
shipped with the MIT krb5 source release.  Who's the vendor?  If someone
else writes a plugin which requires the same per-principal metadata,
should it use different keys because the plugin has a different vendor?