Re: Security Diligence

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