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

[[e-mail] (Martin Rex)]

Jeffrey Hutzelman wrote:
> > With that in mind, a comment like
> > 
> > >
> > > /* It is safe to call gss_release_buffer twice on the same buffer. */
> > 
> > is ambiguous and wrong.
> 
> It's not ambiguous, unless you willfully misinterpret it.
> It _is_ wrong, which is what started this discussion.
> 
> 
> I think we've beat this issue into the ground.
> I think we have something resembling consensus that the example code
> should avoid double-releasing, even though what it _actually does_
> happens to be safe with current major GSS implementations.  Therefore,
> we should stop arguing about it.
 
OK.

> 
> That leaves open the question of what, if any, changes should be made to
> the spec.  There are some on which I suspect there is mostly agreement,
> and one which seems to be controversial.  Nico seems to believe it
> should be explicitly safe to call gss_release_buffer() on a
> gss_buffer_desc that has already been released.  I think I agree.  But
> we must be clear here -- we are talking about two calls with _pointers
> to the same structure_, not calls with pointers to different structures
> that started out with the same value.  In other words, we want to make
> the example code's assumption safe.
 
There is an explicit notion of an empty buffer in the C-Bindings
Header file:  GSS_C_EMPTY_BUFFER
IMHO, it would be difficult for a gssapi mechanism to argue to
be compliant to rfc2744 when breaking on a gss_release_buffer()
call that is passed an empty buffer, because the semantics of
a gss_buffer_desc with {0, 0} contents is well-defined in the
GSS-API C-Bindings.


http://tools.ietf.org/html/rfc2744#page-6

   3.2. String and similar data

   Many of the GSS-API routines take arguments and return values that
   describe contiguous octet-strings.  All such data is passed between
   the GSS-API and the caller using the gss_buffer_t data type.  This
   data type is a pointer to a buffer descriptor, which consists of a
   length field that contains the total number of bytes in the datum,
   and a value field which contains a pointer to the actual datum:

   typedef struct gss_buffer_desc_struct {
      size_t    length;
      void      *value;
   } gss_buffer_desc, *gss_buffer_t;

   Storage for data returned to the application by a GSS-API routine
   using the gss_buffer_t conventions is allocated by the GSS-API
   routine.  The application may free this storage by invoking the
   gss_release_buffer routine.  Allocation of the gss_buffer_desc object
   is always the responsibility of the application;  unused
   gss_buffer_desc objects may be initialized to the value
   GSS_C_EMPTY_BUFFER.


-Martin