Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:72409 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 95803 invoked from network); 8 Feb 2014 16:45:08 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 8 Feb 2014 16:45:08 -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:46460] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E5/60-28087-21F56F25 for ; Sat, 08 Feb 2014 11:45:07 -0500 Received: (qmail 13988 invoked by uid 89); 8 Feb 2014 16:45:04 -0000 Received: by simscan 1.3.1 ppid: 13979, pid: 13984, t: 0.0626s 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; 8 Feb 2014 16:45:04 -0000 Message-ID: <52F65FCD.4060403@lsces.co.uk> Date: Sat, 08 Feb 2014 16:48:13 +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: internals@lists.php.net References: <52F61A78.1020401@lsces.co.uk> <52F62B08.6050201@ajf.me> <52F63DDE.6090600@lsces.co.uk> <52F657E4.4030603@cubiclesoft.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] Security Diligence From: lester@lsces.co.uk (Lester Caine) Pádraic Brady wrote: > The RFCs do imply some awareness of > security and that's largely unavoidable unless each and every RFC > needs to be a 1000 page masterwork;). Since 'security experts' tend not to wait for fixes to be produced before publishing exploits all I am looking for in this case is enough help in the rfc's to assess if action is required before fixes ARE published! And I hope that since these are security fixes that they are pushed back as far as PHP5.3 since this is still under support for security fixes? It is even more important if the fixes are not being rolled back that the extent of the risk is recorded well enough for users to understand the risk? Are these sort of security issues 'support' issues rather than 'internals'? -- 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