Project review: GSS credential store extensions

Sam Hartman hartmans at MIT.EDU
Thu Jul 12 10:19:31 EDT 2012

I'd like to speak in support of const char * here at least for the URN
parameter.  Yes, it's not entirely consistent with existing GSS usage.
However we all know that we'll be happier if we do it that way and the
API will be easier to use.  The only argument I can see for wanting
gss_buffer_(t|desc) for the value is if we expect there are values with
internal nulls.

We should also think about the use of an elements struct in terms of our
experience with GSS-API memory allocation.  As designed today all the
element struct manipulation is left up to the application. The down
sides there are that it makes it expensive and messy if the mechglue or
a stacked mechanism wants to manipulate the element set. Also, it forces
applications to do a bunch of redundant memory management and everyone
is probably going to write there own release functions.

On the other hand, if we do something else, we need to consistently use
it and design it so that a single allocator can be used.


More information about the krbdev mailing list