From dev-return-22456-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Fri Oct 16 16:10:53 2009 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 65682 invoked from network); 16 Oct 2009 16:10:53 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 16 Oct 2009 16:10:53 -0000 Received: (qmail 753 invoked by uid 500); 16 Oct 2009 16:10:53 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 657 invoked by uid 500); 16 Oct 2009 16:10:53 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 641 invoked by uid 99); 16 Oct 2009 16:10:53 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 16 Oct 2009 16:10:53 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [72.167.82.83] (HELO p3plsmtpa01-03.prod.phx3.secureserver.net) (72.167.82.83) by apache.org (qpsmtpd/0.29) with SMTP; Fri, 16 Oct 2009 16:10:44 +0000 Received: (qmail 12907 invoked from network); 16 Oct 2009 16:10:21 -0000 Received: from unknown (76.252.112.72) by p3plsmtpa01-03.prod.phx3.secureserver.net (72.167.82.83) with ESMTP; 16 Oct 2009 16:10:21 -0000 Message-ID: <4AD89AEC.7020908@rowe-clan.net> Date: Fri, 16 Oct 2009 11:10:20 -0500 From: "William A. Rowe, Jr." User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: dev@apr.apache.org Subject: Re: apr_crypto API review References: <20091016154530.GA11446@redhat.com> In-Reply-To: <20091016154530.GA11446@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Joe Orton wrote: > > ** Is the caller of this code expected to be crypto-toolkit agnostic or > not? I am struggling to imagine in Fedora, why we'd want to build > APR(-util) with support for *both* crypto toolkits at run-time. Why not > just pick one at build time, like every other project in the entire > world does? They must be for using the API. If they want to then do something 'more' and address a toolkit directly, that's their perogative, but not something we should even get involved in or claim to support (same issue as svn bdb assumptions). Five practical illustrations related to httpd on win32 out of the box; * ht* support should not bind to/load into process the crypto/ssl libs, ever. Removing the ssl stub[s] due to local laws mustn't invalidate such programs. * user has desire to use ms crypto providers, support this, they must fight with their own registration of certs/keys in the registry. * user has desire to use openssl * user has desire to use openssl compiled as FIPS [these must be seperate libs, see recent dev@openssl.o discussions] * user has 3rd party module using nss directly, seeks to avoid incompatibilities (note the libld platforms suffer much worse than win32 in this respect). I've seen this particular issue repeated year after year in new forms. Fedora is relatively homogeneous so I doubt it would benefit, but again we can offer the disable dso support flags for platforms who rather build in that manner.