Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72403
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.204 cause and error)
Message-ID: <52F63DDE.6090600@lsces.co.uk>
Date: Sat, 08 Feb 2014 14:23:26 +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 <internals@lists.php.net>
References: <52F61A78.1020401@lsces.co.uk> <CAF+90c9ZmeysC88ghHk50rpv_8T4jYhGCWEDwZxOR5EmPuDDLg@mail.gmail.com> <52F62B08.6050201@ajf.me>
In-Reply-To: <52F62B08.6050201@ajf.me>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Security Diligence
From: lester@lsces.co.uk (Lester Caine)

Andrea Faulds wrote:
> On 08/02/14 12:08, Nikita Popov wrote:
>> I'm sorry, but how does this relate to the internals mailing list?
>
> I might be reading it wrong, but I think Lester's saying "don't change PHP in
> ways that force people to make their code secure, because it doesn't matter if
> *my* code's insecure".

You are reading me wrong - as is Nikita ...
My own code is doing exactly as it has done for many years now with a level of 
security that the customer is happy with. Adding any more is unnecessary, but 
'security advisors' dictate otherwise without actually accessing the risk!
But what I'm asking for is that the documentation of the attempts to fix these 
perceived threats includes just a little more information so those of us who are 
not so 'expert' can better understand the nature of the risk?
Simply quoting third party articles like the wikipedia one does not address how 
a risk actually relates to PHP.

Specifically looking at the 'timing attack', as I understand it, if a comparison 
process scans all elements and simply sets a flag when failure is detected which 
is not used until all characters have been processed. Which is the reason for 
establishing 'safely' the number of characters involved. Using 64bit functions 
rather than 32bit will also change the way that process works?

Much of the difficulty I have with PHP these days is simply trying to understand 
why the 'new' method of working is better than what we did 10 or more years ago. 
Good examples of practice is still very lacking even in the latest 
documentation, and what goes into rfc's these days is the basis for updating the 
main documentation?

-- 
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