Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-02.txt (fwd)

[[e-mail] (Martin Rex)]

Greg Hudson wrote:
> 
>> Finally, the C sample code has a comment (in two places, actually):
>> /* It is safe to call gss_release_buffer twice on the same buffer. */
>> This could potentially be misleading, as I believe our conclusion was
>> that 2743/2744 do not explicitly require this to be safe.  However, we
>> believe that it is safe in all known implementations, and that an
>> implementation where it was not safe would be very difficult to use
>> correctly.  Is it reasonable to leave this comment in place under the
>> reasoning that it is describing the assumptions made by the sample code
>> (as opposed to describing the behavior mandated by the specification)?
> 
> I think it's reasonable to retroactively standardize this behavior of
> gss_release_buffer, if it's a property of every implementation we're
> aware of.

I hadn't notice this strange comment about gss_release_buffer() before,
and I'm voilently opposed, please remove that misleading comment.

None of the GSS-API calls makes any kind of promise that calling
it twice would be safe.  Actually, if you look at how the C-Bindings
were designed, just the opposite has to be assumed.

The convention to pass the pointers (and gss_buffer_desc) by reference
to the release function, so that the function could zero out the
references/pointers to resources that were allocated by the library
appears specifically designed to make it less likely that a program
will crash when calling a function twice -- _provided_ that it passes
the _original_ reference to the release function (which can then be zeroed),
rather than a mere copy of it (which could not possibly protect from
being called again with other non-zero copies of the original).


The only thing that a release function can be expected to recognize
and handle safely is being called with an already zero-ed handle
or already-zeroed value pointer in gss_buffer_desc.

-Martin