Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72328
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <52F33350.1060800@sugarcrm.com>
References: <9E3AA302-1EC1-4497-996F-716555CAAB64@rouvenwessling.de>
	<CAF+90c-32u=vVy4L4pB_OWGu2VmeUckxq8UW_AVJNC8iDtiWMQ@mail.gmail.com>
	<52F0139C.2060102@sugarcrm.com>
	<CAGa2bXZhT_8-BEjLuA4EPkZmxtpO1onz7AGTjCE-w85XC5pwdQ@mail.gmail.com>
	<CAGa2bXYab=2DeJu+ESWP_9Vte2FY37L2+kJFnuN4JwUj9Num1w@mail.gmail.com>
	<AC16ADC6-801E-4D0D-9FD4-0BEE2D017E16@rouvenwessling.de>
	<CAGa2bXa0i6LBykCNChcCXS+zgp+3KfMEi+H=umFAwL1mC0s__Q@mail.gmail.com>
	<CAGa2bXZpcjichYTB1kXDJ5dp4dcB2rdR1jAQo=TKtSK2cNqZFQ@mail.gmail.com>
	<52F30E3B.1090302@oracle.com>
	<CAEZPtU7q=JGj+HzCPterVWFEL4YykrfAkPwhbFwt1WnHBMHadQ@mail.gmail.com>
	<52F33350.1060800@sugarcrm.com>
Date: Thu, 6 Feb 2014 08:09:06 +0100
Message-ID: <CAEZPtU5rcUn=p5Tf+QimWOnKW1tcm8X5srEsEu6zsZ6FE8w+Ww@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [VOTE] Timing attack safe string comparison function
From: pierre.php@gmail.com (Pierre Joye)

On Thu, Feb 6, 2014 at 8:01 AM, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
> Hi!
>
>> We do not have to over react here, it is, for a change, that there is
>> clear consensus about the need or wish for this feature. It is not a
>> trivial thing to implement but we have time to make it rock solid
>> until final 5.6.0.
>
> There's a consensus about the feature as it was proposed,

For what I see there is one:

https://wiki.php.net/rfc/timing_attack

> but when all
> kind of things start to be added to it, that eventually becomes a
> different feature from one that was voted on.

What I mean is that the need of a function to do hash equality tests
with time attacks protection got a positive consensus. The
implementation details are indeed subject to change and will certainly
get updates until 5.6.0 final, and surely afterwards as well.

> If the proposal is not
> ready, then the vote should be delayed. If it's ready then the constant
> stream of changes, tweaks and additions looks strange - it's really hard
> to know what the vote is actually about.

There are a couple of caveats that need to be solved. Not sure it
needs a new vote but that should not be a problem to redo it. My point
is that such feature seems to be desired for 5.6 and we should try to
make sure it gets in, as long as it is possible.

Cheers,
--
Pierre

@pierrejoye | http://www.libgd.org