[krbdev.mit.edu #2609] [Nicolas Williams] Re: krb5_gss_internal_release_oid

Tom Yu via RT rt-comment at krbdev.mit.edu
Thu Dec 9 15:38:45 EST 2004


-------------------- Start of forwarded message --------------------
Date: Wed, 8 Dec 2004 16:32:55 -0600
From: Nicolas Williams <Nicolas.Williams at sun.com>
To: Kevin Coffman <kwc at citi.umich.edu>
Message-ID: <20041208223255.GE135800 at binky.central.sun.com>
References: <20041208221833.B91401BAAD at citi.umich.edu>
In-Reply-To: <20041208221833.B91401BAAD 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).

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

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



More information about the krb5-bugs mailing list