Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by krbdev.mit.edu (8.9.3p2) with ESMTP id RAA29042; Fri, 29 Dec 2006 17:20:49 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id kBTMKjnK015655 for <rt@krbdev.MIT.EDU>; Fri, 29 Dec 2006 17:20:45 -0500 (EST)
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id kBTMKi3M024018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rt@krbdev.MIT.EDU>; Fri, 29 Dec 2006 17:20:45 -0500 (EST)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9) id kBTMKiCf001720; Fri, 29 Dec 2006 17:20:44 -0500 (EST)
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5233] Change in behaviour in gss_release_buffer() by mechtypes introduces memory leak
References: <rt-5233-21709.2.75279040894887@krbdev.mit.edu>
From: Tom Yu <tlyu@MIT.EDU>
Date: Fri, 29 Dec 2006 17:20:44 -0500
In-Reply-To: <rt-5233-21709.2.75279040894887@krbdev.mit.edu> (Ezra Peisach via's message of "Fri, 29 Dec 2006 17:05:55 -0500 (EST)")
Message-Id: <ldvk60as5s3.fsf@cathode-dark-space.mit.edu>
Lines: 17
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-BY: MIMEDefang 2.42
X-Spam-Flag: NO
X-Spam-Score: 0.00
RT-Send-Cc: 
X-RT-Original-Encoding: us-ascii
Content-Length: 800

>>>>> "Ezra" == Ezra Peisach via RT <rt-comment@krbdev.mit.edu> writes:

Ezra> Sam Hartman via RT wrote:
>> Note that callers should not be releasing buffers that they allocated.
>> So I think we need only be consistent within our implementation and
>> within mechanisms that plug into our implementation.
>> 
>> 
Ezra> Exactly....  The mechanism interface has changed the implementation 
Ezra> requirements.  The release_buffer is not passed down to the mech 
Ezra> specific handlers.  So - self consistency in the implementation would 
Ezra> now require a change in the k5sealv3.c code...

I think some interpretations of the spec require that an application
be able to assume that a zero length buffer doesn't need to be
released.  We should probably adjust k5sealv3.c to be consistent with
that.