Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:69229 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 84486 invoked from network); 19 Sep 2013 09:17:23 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 19 Sep 2013 09:17:23 -0000 Authentication-Results: pb1.pair.com header.from=addw@phcomp.co.uk; sender-id=permerror Authentication-Results: pb1.pair.com smtp.mail=addw@phcomp.co.uk; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain phcomp.co.uk designates 78.32.209.33 as permitted sender) X-PHP-List-Original-Sender: addw@phcomp.co.uk X-Host-Fingerprint: 78.32.209.33 freshmint.phcomp.co.uk Received: from [78.32.209.33] ([78.32.209.33:36567] helo=mint.phcomp.co.uk) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D1/99-29009-221CA325 for ; Thu, 19 Sep 2013 05:17:23 -0400 Received: from addw by mint.phcomp.co.uk with local (Exim 4.72) (envelope-from ) id 1VMaMR-0005Oh-KI for internals@lists.php.net; Thu, 19 Sep 2013 10:17:19 +0100 Date: Thu, 19 Sep 2013 10:17:19 +0100 To: internals@lists.php.net Message-ID: <20130919091719.GB17282@phcomp.co.uk> Mail-Followup-To: internals@lists.php.net References: <523A466C.4070903@gmail.com> <000101ceb516$7ba80540$72f80fc0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000101ceb516$7ba80540$72f80fc0$@net> Organization: Parliament Hill Computers Ltd User-Agent: Mutt/1.5.20 (2009-12-10) Subject: Re: [PHP-DEV] Re: Re: PHP Crypt functions - security audit From: addw@phcomp.co.uk (Alain Williams) On Thu, Sep 19, 2013 at 09:58:59AM +0100, Chris Wright wrote: > On Thu, Sep 19, 2013 at 2:07 AM, Tjerk Anne Meesters > wrote: > > To be practical, verifying certificates requires an up-to-date CA bundle > > to be shipped with PHP; perhaps this is a simple thing to do, I'm not > > sure. > > Unfortunately it isn't. It's easily possible to ship a current CA bundle > *at the point when PHP is built/installed* but this needs to be *kept* up > to date in order to remain useful. In the real world, people don't update > production servers with every new release and the CA bundle that was > correct at the time of print (as it were) would soon become outdated - > although arguably an outdated bundle is better than nothing. Agreed, however few people take PHP from the sources & compile it themselves. Most people will use the PHP that comes with their operating system and will expect their vendor/distributor to keep it up to date (security patches, etc). If the PHP project includes a CA bundle that is kept up to date then the vendor/distributors can update their customers as & when. It is not realistic to expect someone who is running a small web server to put the time into monitoring if they have up to date CA bundles; even if they understand what it is all about they probably don't have the time. This is what people expect the operating system vendor/distributor to do for them; end users will generally install updates when they become available, they generally have a hazy idea what these updates to -- that is OK, they have other things to worry about. What I am saying is that the PHP project should include a CA bundle, probably as a separately installable component that can be updated separately. This will help the vendors/distributors to push out updates to their users. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include