[krbdev.mit.edu #2609] [Kevin Coffman] Re: krb5_gss_internal_release_oid

[Tom Yu via RT]

-------------------- Start of forwarded message --------------------
To: Kevin Coffman <kwc at citi.umich.edu>, krb5-prs at mit.edu
In-Reply-To: Message from Nicolas Williams <Nicolas.Williams at sun.com> 
	<20041208223255.GE135800 at binky.central.sun.com> 
Date: Wed, 08 Dec 2004 17:44:53 -0500
From: Kevin Coffman <kwc at citi.umich.edu>
Message-Id: <20041208224454.0726A1BB9A at citi.umich.edu>
Subject: Re: krb5_gss_internal_release_oid 
Lines: 31

> On Wed, Dec 08, 2004 at 05:18:33PM -0500, Kevin Coffman wrote:
> > The subject function was made static in 1.3 (I believe).  This function 
> > is needed by the gss mechglue code to function properly when multiple 
> > mechanisms are being used.
> 
> Wrong...
> 
> ...mostly :)
> 
> GSS_Release_OID() was removed from the GSS-API in version 2, update,
> a.k.a., RFC2743.
> 
> The reason is that GSS OIDs are, and should be, constant, or effectively
> so anyway, such that there is never a need to release them.
> 
> Yes, stackable pseudo-mechanisms will lead to the construction of OIDs
> at runtime, for implementations of them that are truly dynamic, but even
> so, GSS-API applications will not have to release such OIDs, nor should
> the mechglue care to do it either as finalization of the mechanisms
> should take care of releasing resources associated with such one-time
> constructions (or, if you just don't care, leak the things).
> 
> If you find you need gss_release_oid() then something's wrong with the
> mechglue (I know, I know, I know).

Yes, sorry.  I realized this at one time but forgot it.

_______________________________________________
krb5-bugs mailing list
krb5-bugs at mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs

-------------------- End of forwarded message --------------------