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 RAA29028; Fri, 29 Dec 2006 17:05:51 -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 kBTM5bHx009117 for ; Fri, 29 Dec 2006 17:05:38 -0500 (EST) Received: from [192.168.1.47] (pool-71-126-50-180.bstnma.east.verizon.net [71.126.50.180]) (authenticated bits=0) (User authenticated as epeisach@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id kBTM5aGg022415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 29 Dec 2006 17:05:37 -0500 (EST) Message-Id: <4595912F.7000309@mit.edu> Date: Fri, 29 Dec 2006 17:05:35 -0500 From: Ezra Peisach User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: rt-comment@krbdev.mit.edu Subject: Re: [krbdev.mit.edu #5233] Change in behaviour in gss_release_buffer() by mechtypes introduces memory leak References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-BY: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 RT-Send-Cc: X-RT-Original-Encoding: iso-8859-1 Content-Length: 490 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. > > Exactly.... The mechanism interface has changed the implementation requirements. The release_buffer is not passed down to the mech specific handlers. So - self consistency in the implementation would now require a change in the k5sealv3.c code... Ezra