Return-Path: Delivered-To: apmail-xml-security-dev-archive@www.apache.org Received: (qmail 31954 invoked from network); 17 Oct 2005 12:06:37 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 17 Oct 2005 12:06:37 -0000 Received: (qmail 34223 invoked by uid 500); 17 Oct 2005 12:06:26 -0000 Delivered-To: apmail-xml-security-dev-archive@xml.apache.org Received: (qmail 34208 invoked by uid 500); 17 Oct 2005 12:06:25 -0000 Mailing-List: contact security-dev-help@xml.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: Reply-To: security-dev@xml.apache.org List-Id: Delivered-To: mailing list security-dev@xml.apache.org Received: (qmail 34185 invoked by uid 99); 17 Oct 2005 12:06:25 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 Oct 2005 05:06:25 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [194.128.225.190] (HELO spmler1.mail.eds.com) (194.128.225.190) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 Oct 2005 05:06:25 -0700 Received: from spmlir2.mail.eds.com (spmlir2.mail.eds.com [205.191.69.42] (may be forged)) by spmler1.mail.eds.com (8.13.2/8.12.10) with ESMTP id j9HC62iA029775 for ; Mon, 17 Oct 2005 13:06:02 +0100 Received: from spmlir2.mail.eds.com (localhost.localdomain [127.0.0.1]) by spmlir2.mail.eds.com (8.13.4/8.12.10) with ESMTP id j9HC5QKv004085 for ; Mon, 17 Oct 2005 13:05:26 +0100 Received: from ukspm010.emea.corp.eds.com ([204.230.90.155]) by spmlir2.mail.eds.com (8.13.4/8.12.10) with ESMTP id j9HC5QPr004080 for ; Mon, 17 Oct 2005 13:05:26 +0100 Received: from ukspm204.emea.corp.eds.com ([204.230.90.193]) by ukspm010.emea.corp.eds.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Oct 2005 13:05:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D313.0FA9E387" Subject: [C++] more memory leaks in windows WinCAPICryptoXXXX files Date: Mon, 17 Oct 2005 13:05:27 +0100 Message-ID: <4F014656062C1140880B2247EDAFD3B102E0750A@ukspm204.emea.corp.eds.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [C++] more memory leaks in windows WinCAPICryptoXXXX files Thread-Index: AcXTEw98TZ8kKk/bQqCoC4p+H2EHHQ== From: "Cullum, Steve" To: X-OriginalArrivalTime: 17 Oct 2005 12:05:25.0448 (UTC) FILETIME=[0EB48C80:01C5D313] X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D313.0FA9E387 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Some more potential memory leaks in the following files .. I have not tested all of them=20 \xml-security\c\src\enc\WinCAPI\WinCAPICryptoHashHMAC.cpp(211): HCRYPTHASH h; \xml-security\c\src\enc\WinCAPI\WinCAPICryptoHashHMAC.cpp(339): HCRYPTHASH h; \xml-security\c\src\enc\WinCAPI\WinCAPICryptoKeyDSA.cpp(348): HCRYPTHASH h; \xml-security\c\src\enc\WinCAPI\WinCAPICryptoKeyDSA.cpp(422): HCRYPTHASH h; \xml-security\c\src\enc\WinCAPI\WinCAPICryptoKeyRSA.cpp(300): HCRYPTHASH h; \xml-security\c\src\enc\WinCAPI\WinCAPICryptoKeyRSA.cpp(369): HCRYPTHASH h; It looks like these local objects never get freed by CryptDestroyHash().. on failure or success! There is a wrapper "class" WinCAPICryptoHash, but I don't think it was intended for the purpose of resource management. With some simple changes it could do the job. It looks like a resource wrapper is the best option, as many of the fn()'s that use the HCRYPTHASH can terminate early by throw'ing errors. Hope this helps Steve ------_=_NextPart_001_01C5D313.0FA9E387 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [C++] more memory leaks in windows WinCAPICryptoXXXX = files

Some more potential memory leaks = in the following files .. I have not tested all of them

\xml-security\c\src\enc\WinCAPI\WinCAPICryptoHashHMAC.cpp(211): = ;   HCRYPTHASH h;
\xml-security\c\src\enc\WinCAPI\WinCAPICryptoHashHMAC.cpp(339): = HCRYPTHASH h;
\xml-security\c\src\enc\WinCAPI\WinCAPICryptoKeyDSA.cpp(348): &= nbsp; HCRYPTHASH h;
\xml-security\c\src\enc\WinCAPI\WinCAPICryptoKeyDSA.cpp(422): &= nbsp; HCRYPTHASH h;
\xml-security\c\src\enc\WinCAPI\WinCAPICryptoKeyRSA.cpp(300): &= nbsp; HCRYPTHASH h;
\xml-security\c\src\enc\WinCAPI\WinCAPICryptoKeyRSA.cpp(369): &= nbsp; HCRYPTHASH h;

It looks like these local objects = never get freed by CryptDestroyHash().. on failure or success!

There is a wrapper = "class" WinCAPICryptoHash, but I don’t think it was = intended for the purpose of resource management.  With some simple = changes it could do the job.  It looks like a resource wrapper is = the best option, as many of the fn()'s that use the HCRYPTHASH can = terminate early by throw'ing errors.

Hope this helps

Steve






------_=_NextPart_001_01C5D313.0FA9E387--