Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93821
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.42 as permitted sender)
MIME-Version: 1.0
Sender: jakub.php@gmail.com
In-Reply-To: <CAKws9z3tW8w+2+27fx9DcojqCY5EScQPUVMqHGBuZA8b9BBJoQ@mail.gmail.com>
References: <CAKws9z114YcHkDaXO3o-E0JuHR10WsPzyedeF_8Q=shHDziwug@mail.gmail.com>
 <f19972fa-353f-dc6c-6184-9f1c72ad2ce7@gmail.com> <CAEZPtU4aSoe3rDWWFssBx95pgqXe=TXT52bGi_85X+cYmqjH0A@mail.gmail.com>
 <CAKws9z0qrT2etrx5K3xFLOEPfeV0E7Z_F5nDDc-PmYqck8++Cg@mail.gmail.com>
 <8ebf9e48-62e5-fae5-d234-448be3c1f9d2@fleshgrinder.com> <CAKws9z3zCUPtsCu6QsFBMG4DOPE-ecsnOMaYP_TOgf5O-7UNAQ@mail.gmail.com>
 <d083b26b-2fb2-42a9-eb3d-1c4d63db3bec@fleshgrinder.com> <CAKws9z3tW8w+2+27fx9DcojqCY5EScQPUVMqHGBuZA8b9BBJoQ@mail.gmail.com>
Date: Sun, 5 Jun 2016 20:33:27 +0100
Message-ID: <CAEKnhAHBCYC43kpgiv_A_CN6cg9sKaGmUP09MdL7As2hnwj_5A@mail.gmail.com>
To: Scott Arciszewski <scott@paragonie.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114dd93eb7ceb605348d079a
Subject: Re: [PHP-DEV] [RFC] Libsodium - Discussion
From: bukka@php.net (Jakub Zelenka)

--001a114dd93eb7ceb605348d079a
Content-Type: text/plain; charset=UTF-8

On Sun, Jun 5, 2016 at 9:35 AM, Scott Arciszewski <scott@paragonie.com>
wrote:

> On Sun, Jun 5, 2016 at 4:31 AM, Fleshgrinder <php@fleshgrinder.com> wrote:
> > On 6/5/2016 10:23 AM, Scott Arciszewski wrote:
> >> I'm trying to keep concerns separate. I do want to make the pluggable
> >> crypto API happen, but I barely have time for this libsodium RFC and I
> >> don't want to conflate the two. (Even worse: I wouldn't want the mere
> >> thought of an abstract high-level API to block libsodium from getting
> >> accepted.)
> >>
> >> Instead of /completely redesigning/ the libsodium API, what are some
> >> changes that need to be made to alleviate the majority of concerns
> >> ("it's not the pluggable crypto API" notwithstanding)?
> >>
> >> Two things to keep in mind:
> >>
> >> 1. If it breaks existing code that uses libsodium-php in a nontrivial
> >> way, I'm going to resist the change unless it can be proven necessary
> >> for the sake of everyone's sanity.
> >> 2. If it greatly deviates from the experience of using libsodium in
> >> other programming languages (e.g. renaming crypto_box), you no longer
> >> have libsodium and thus I will resist it.
> >>
> >> Getting rid of redundant features (by improving existing ones, not
> >> just cutting them!) is fine. Dropping scrypt, etc. is fine.
> >>
> >
> > Keeping sodium as an extension solves all your problems. You can keep
> > evolving it in any way you like without having to argue with others. No
> > breaking changes, nothing. It can even be used after another API is
> > introduced in core.
>
> All my problems? How do I get non-root users to install it?
>

I don't really get this point. All main distros have separate packages for
the core extensions as well as for PECL extensions. You still need a root
access to install the extension and it doesn't matter if it's a core ext or
PECL ext. There are lots of extensions that do really well outside the core
(e.g. mongo). So why do we really need it in the core?

Personally I find libsodiam a nice extension that provides some cool stuff.
However I don't see a big benefit of adding that to the core. We already
struggle to maintain the current extensions and even if you said that you
would maintain it, we should also take into account the fact that it can
change and we might end up with another unmaintained ext.

Cheers

Jakub

--001a114dd93eb7ceb605348d079a--