Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:72184 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 49721 invoked from network); 4 Feb 2014 08:27:10 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Feb 2014 08:27:10 -0000 Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.204 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.204 mail4.serversure.net Linux 2.6 Received: from [217.147.176.204] ([217.147.176.204:32991] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 18/87-09069-B54A0F25 for ; Tue, 04 Feb 2014 03:27:09 -0500 Received: (qmail 4916 invoked by uid 89); 4 Feb 2014 08:27:04 -0000 Received: by simscan 1.3.1 ppid: 4907, pid: 4911, t: 0.0684s scanners: attach: 1.3.1 clamav: 0.96/m:52 Received: from unknown (HELO linux-dev4.lsces.org.uk) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 4 Feb 2014 08:27:04 -0000 Message-ID: <52F0A501.8030105@lsces.co.uk> Date: Tue, 04 Feb 2014 08:29:53 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 SeaMonkey/2.23 MIME-Version: 1.0 To: PHP internals References: <344075933.20140203143339@figureone.com> <617796370.20140204005840@cypressintegrated.com> <52F098F7.7000901@lsces.co.uk> <52F09D64.9020803@lsces.co.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: Windows Peer Verification From: lester@lsces.co.uk (Lester Caine) Pierre Joye wrote: > On Tue, Feb 4, 2014 at 8:57 AM, Lester Caine wrote: >> Pierre Joye wrote: >>>> >>>> Security is not the >>>>> only thing that is reliant nowadays on third party data? >>> >>> We bundle the TZ data and it is used on all supported platforms. So >>> no, no platform lags behind other. Some distributions may patch the >>> date extension to use the system TZ but then it is none of our >>> business. >> >> >> But that is the whole point here ... it's the same argument with CA file? > > If someone distributes a patched PHP, it is none of our business. > > And CA file on Windows is not the same issue as Windows do not have > system CA files compatible with OpenSSL. Implementing a backend using > windows keys store and SSL APIs would bring more issues and > incompatibilities (user lever) than asking users to set an ini > setting. OK that is making sense. The only reason that the tz data sprang to mind is a similar situation. Up until now windows has also had it's own timezone data management, so was not compatible with tz, but it seems from information being received that newer versions of windows are now using the tz data itself as it was their data which was lagging behind the real world. Linux distributions do update their tz data, but windows installs of PHP can't take advantage of the same update path? Just like the CA files. It's PHP distributing the 'patched' windows builds here? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk