Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90856
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEKnhAHJW_v-yHx8ZJwu8O63Yfwc+9+bJnRoJwH7qXdzWE8T=w@mail.gmail.com>
References: <CAEKnhAHJW_v-yHx8ZJwu8O63Yfwc+9+bJnRoJwH7qXdzWE8T=w@mail.gmail.com>
Date: Sat, 23 Jan 2016 22:01:05 +0100
Message-ID: <CADyq6sKcmXSm9ouGS-K_+0hNm=vnUq4Fa_BpW=OHYZ1+b4V4uA@mail.gmail.com>
To: Jakub Zelenka <bukka@php.net>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c342b688d264052a06a306
Subject: Re: [PHP-DEV] [RFC][VOTE] OpenSSL AEAD support
From: ocramius@gmail.com (Marco Pivetta)

--001a11c342b688d264052a06a306
Content-Type: text/plain; charset=UTF-8

Just FYI, I'm voting against this proposal, as the number of parameters is
simply growing out of control, which involves:
 - more BC breaks if default parameters change
 - more security issues if the defaults are unsafe (or become unsafe, for
whatever reason)
 - more cognitive load (it's arguably more complex)

In general, this simply pushes too many responsibilities on the interface.
Support for AEAD can be moved to a separate function, which involves a
minor BC break: collision with pre-existing functions, if anybody was
crazy/stupid enough to implement crypto in userland, and even worse in the
global namespace.


Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

On 20 January 2016 at 17:40, Jakub Zelenka <bukka@php.net> wrote:

> Hi,
>
> The vote is now open:
>
> https://wiki.php.net/rfc/openssl_aead#voting
>
> Cheers
>
> Jakub
>

--001a11c342b688d264052a06a306--