Project review: GSS credential store extensions

[Greg Hudson]

On 07/12/2012 12:43 PM, Sam Hartman wrote:
> Ok. Well, add me to Nico in the strong disagreement camp here.

Well, that's unfortunate.

Can you make a specific proposal?  At the moment, I don't feel like I
have a good path forward here other than disregarding your objections.
We have no precedent in GSSAPI for opaque collection types.  When I try
to design one in my head, (1) the API footprint becomes large very
quickly, and (2) it doesn't meet all of the design objectives.

Remember that a mechanism doesn't necessarily have the ability to call
functions in the mechglue which invoked it.  (Or at least, that's your
deployment constraint for Moonshot, since you want to be able to
distribute a binary module which can be loaded by multiple mechglues.)

> If it
> were just the buffers, I would agree with you.  
> I'm actually a bit puzzled about why you're bringing up buffers though;
> this structure does not include buffers.

I brought up buffers as an instructive example of where using a
non-opaque structure has harmed us in the past.  (However, if GSS
buffers were opaque, that would probably involve additional copying,
which is something people are unwilling to do to resolve the
mechglue/mech ambiguity, so I'm not sure how we would have avoided this
problem given perfect foresight.)

> Even if Nico and I aren't able to build a consensus in favor of a better
> memory management approach, I think it's critical that we document the
> assumptions of this approach.  Namely, you cannot free a cred_set you
> didn't allocate. You cannot manipulate one; you must copy to manipulate.

It seems like it's unnecessary to document this at the current stage
(which I hope is the final stage), where cred stores are only ever used
as input parameters, the mechs have no reason to supply one, and there
is no gss_release_cred_store().