Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90472
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAKws9z15+U6F+ywskEfxVqhmqgTWUrmXtZERuKsHjusE+SanyQ@mail.gmail.com>
References: <CAKws9z1g24rD=t92+9xKtO=3PuwQ3_N=L36gmVMqCC84CoqipQ@mail.gmail.com>
	<CAEZPtU7-Lk=jGsTQgRZOvBpcPPgdX3V-23=3_k9CXbmxU77V1A@mail.gmail.com>
	<CAKws9z248Kj=0qTLPZik0Ki1_zGPq+4fr6HQi_keeVCso1S4eQ@mail.gmail.com>
	<5692CDB6.5050905@gmail.com>
	<CAKws9z1e_+XOzsojz9gW-zzswhaK7h+HothhTWWVSvDQXri2zA@mail.gmail.com>
	<5692D424.2010908@gmail.com>
	<CAKws9z15+U6F+ywskEfxVqhmqgTWUrmXtZERuKsHjusE+SanyQ@mail.gmail.com>
Date: Mon, 11 Jan 2016 10:14:35 +0700
Message-ID: <CAEZPtU6u4niYim4rd4VLpL0cwff85pPSg8dV+SkHyRSS_w7vDQ@mail.gmail.com>
To: Scott Arciszewski <scott@paragonie.com>
Cc: Rowan Collins <rowan.collins@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=e89a8ff1ccaa3ca97e0529065660
Subject: Re: [PHP-DEV] [RFC] Libsodium
From: pierre.php@gmail.com (Pierre Joye)

--e89a8ff1ccaa3ca97e0529065660
Content-Type: text/plain; charset=UTF-8

On Jan 11, 2016 5:22 AM, "Scott Arciszewski" <scott@paragonie.com> wrote:
>
> On Sun, Jan 10, 2016 at 4:59 PM, Rowan Collins <rowan.collins@gmail.com>
wrote:
> > On 10/01/2016 21:41, Scott Arciszewski wrote:
> >>
> >> Hi Rowan,
> >>
> >>> >I think what people are suggesting is not that libsodium shouldn't be
> >>> >supported under-the-hood, just that the fact you're using it
shouldn't
> >>> > be
> >>> >exposed to userland.
> >>
> >> These are separate concerns. Let's call them Sodium and SimpleSodium.
> >>
> >> With Sodium, power users gain the ability to write software that
> >> directly uses low-level primitives in PHP without requiring their
> >> users to install dependencies (i.e. from PECL). [
> >>
> >> SimpleSodium is a driver for the simple cryptography wrapper.
> >
> >
> > As noted on the other thread, I think what people are looking for is
> > actually somewhere between the two - something for power users to use
> > *without tying their code to libsodium*. Code written using mcrypt_*
> > functions is now facing an annoying upgrade path; code written with
sodium_*
> > functions now may face the same some years in the future, who knows?
> >
> > PHP should not be maintaining its own low-level implementations of
crypto,
> > but it should seem to the user as though it does - they should be
asking PHP
> > for a particular cipher / mode / etc, not asking libsodium for one via a
> > thin PHP wrapper.
> >
> >
> >> You can have SimpleSodium without Sodium, but if we don't get Sodium
into
> >> core
> >> I will, personally, not be putting forth one more ounce of time or
> >> effort into helping the PHP core so who knows maybe not?
> >
> >
> > Obviously, this is entirely your prerogative, but it seems quite a
> > black-and-white stance - maybe leave a bit of leeway for understanding
other
> > people's concerns before threatening to abandon work which would be very
> > much appreciated.
> >
> >
> > Regards,
> >
> > --
> > Rowan Collins
> > [IMSoP]
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
> Hi Rowan,
>
> > As noted on the other thread, I think what people are looking for is
> > actually somewhere between the two - something for power users to use
> > *without tying their code to libsodium*. Code written using mcrypt_*
> > functions is now facing an annoying upgrade path; code written with
sodium_*
> > functions now may face the same some years in the future, who knows?
>
> And I'm of the opinion that most users need a library that does
> everything for them, and power users need a toolkit, and we shouldn't
> try to solve both use cases with the same library.

This is a valid and good point.

Also agree on the need of the two. Now whether the toolkit should be an
extension or userland can be discussed as well.

Whether sodium (or other) are in the core or  not, the discussions about a
more powerful (also proposing a wider range of options for various tasks,
even using bad cyphers) sound like a good thing and may as well answer the
question about your libsodium binding proposal.

> Some people might
> be allergic to having two separate tools for two separate jobs,

On the other hand they have things in common. But I totally agree on the
userland side. PHP needs a password-like APIs for crypto, where users will
have a hard time to do it wrong.

> but I
> am not one of them. Power-users will need low-level cipher
> implementations, most developers will only write insecure code if we
> let them.
>
> If libsodium gets obsoleted (unlikely), it will be because of the
> availability of practical quantum computers, which also obsoletes
> openssl and all existing public-key cryptography. Mcrypt is unique in
> that it was completely abandoned (and poorly designed, to boot) after
> adoption. I don't think this is a meaningful discussion to have right
> now, given how widespread it is.
>
> https://download.libsodium.org/doc/bindings_for_other_languages/index.html
>

> I'm just letting it be known now where I stand with this now rather
> than later, so if this libsodium initiative doesn't pass and I
> suddenly drop off internals and delete the relevant Github
> repositories for the other projects I proposed, there will be no
> question as to why.

This is your choice and you are indeed free to do it.

I cannot agree on both the killing of repositories in general and even less
of threatens to do so if a given proposal is not accept. It goes against my
principles.

In any case, given that we can have a constructive discussions about the
design and needs, I am sure we will find answers to these questions in the
next couple of weeks.

--e89a8ff1ccaa3ca97e0529065660--