Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72404
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <52F63DDE.6090600@lsces.co.uk>
References: <52F61A78.1020401@lsces.co.uk>
	<CAF+90c9ZmeysC88ghHk50rpv_8T4jYhGCWEDwZxOR5EmPuDDLg@mail.gmail.com>
	<52F62B08.6050201@ajf.me>
	<52F63DDE.6090600@lsces.co.uk>
Date: Sat, 8 Feb 2014 15:26:44 +0100
Message-ID: <CAEZPtU5-DnNeFFJDGYG+YHjL_SOddNeiqcoJp_Ye2G+Lgdu2ow@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Security Diligence
From: pierre.php@gmail.com (Pierre Joye)

On Sat, Feb 8, 2014 at 3:23 PM, Lester Caine <lester@lsces.co.uk> wrote:
> 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, this is not a support list.

It is your good right to stick with dead PHP versions and 10 years old
code (whether it is your choice or not), but it is definitively not
good to constantly posts totally off topic posts, replies or complains
about what we do or don't. It is even more annoying in cases where you
clearly do not understand the underlying reasons of one feature or
another.

That being said, I would love to see you actually contribute something
for a change.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org