Skip Menu |
 

History Show all quoted text — Show full headers
# Wed Jun 23 10:04:42 2004 kwc@citi.umich.edu (Kevin Coffman) - Ticket created
To: krb5-bugs@mit.edu
Date: Wed, 23 Jun 2004 10:04:29 -0400
From: Kevin Coffman <kwc@citi.umich.edu>
Subject: krb5_gss_internal_release_oid
Download (untitled) / with headers
text/plain 354B
It looks like krb5_gss_internal_release_oid was made private in 1.3.

This routine is needed by the mechanism glue code when more than one
mechanism is being used. Otherwise, when krb5_gss_release_oid is
called with an oid of a different mechanism, it calls
generic_gss_release_oid which attempts to free the static storage of
the other mechanism.
# Wed Dec 08 17:28:58 2004 kwc@citi.umich.edu (Kevin Coffman) - Ticket #2798: - Ticket created
To: krb5-bugs@mit.edu
Date: Wed, 08 Dec 2004 17:28:04 -0500
From: Kevin Coffman <kwc@citi.umich.edu>
Cc: Kevin Coffman <kwc@citi.umich.edu>
Subject: krb5_gss_internal_release_oid
Download (untitled) / with headers
text/plain 231B
[Trying again to the correct address...]

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.

Thanks,
Kevin
# Wed Dec 08 17:32:07 2004 tlyu (Taylor Yu) - Ticket #2798: - Ticket 2798 MergedInto ticket 2609.
# Thu Dec 09 09:23:56 2004 kwc@citi.umich.edu (Kevin Coffman) - Correspondence added
To: rt@krbdev.mit.edu
Cc: kwc@citi.umich.edu
Subject: Re: [krbdev.mit.edu #2798] AutoReply: krb5_gss_internal_release_oid
Date: Thu, 09 Dec 2004 09:23:54 -0500
From: Kevin Coffman <kwc@citi.umich.edu>
RT-Send-Cc:
Download (untitled) / with headers
text/plain 297B
Show quoted text
>
> 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.

As Nico pointed out, the use of the internal_release_oid function should
not be necessary. Sorry for the noise...
# Thu Dec 09 15:38:41 2004 tlyu (Taylor Yu) - Correspondence added
To: krb5-bugs@mit.edu
From: Tom Yu <tlyu@mit.edu>
Date: Wed, 08 Dec 2004 17:49:20 -0500
Subject: [krbdev.mit.edu #2609] [Kevin Coffman] Re: krb5_gss_internal_release_oid
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.7KiB

Show quoted text
-------------------- Start of forwarded message --------------------
To: Kevin Coffman <kwc@citi.umich.edu>, krb5-prs@mit.edu
In-Reply-To: Message from Nicolas Williams <Nicolas.Williams@sun.com>
<20041208223255.GE135800@binky.central.sun.com>
Date: Wed, 08 Dec 2004 17:44:53 -0500
From: Kevin Coffman <kwc@citi.umich.edu>
Message-Id: <20041208224454.0726A1BB9A@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@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs

-------------------- End of forwarded message --------------------
# Thu Dec 09 15:38:41 2004 tlyu (Taylor Yu) - Correspondence added
To: krb5-bugs@mit.edu
From: Tom Yu <tlyu@mit.edu>
Date: Wed, 08 Dec 2004 17:40:18 -0500
Subject: [krbdev.mit.edu #2609] [Nicolas Williams] Re: krb5_gss_internal_release_oid
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.6KiB

Show quoted text
-------------------- Start of forwarded message --------------------
Date: Wed, 8 Dec 2004 16:32:55 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Kevin Coffman <kwc@citi.umich.edu>
Message-ID: <20041208223255.GE135800@binky.central.sun.com>
References: <20041208221833.B91401BAAD@citi.umich.edu>
In-Reply-To: <20041208221833.B91401BAAD@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@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs

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