Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98056
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain paragonie.com designates 209.85.218.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEKnhAF5yoO671XMa-1XE1=2UYBCtTjUcHp5cF8s_zLeS1enxw@mail.gmail.com>
References: <CAKws9z2x1wz_WA9_XWOjbf-M9m917DN=zWzhXw3JNqdewyL_9g@mail.gmail.com>
 <CAEKnhAFrgh30fj8Hjm-OEOKkdyPkGbYfeSbxci4a9+5sja-c_Q@mail.gmail.com>
 <CAKws9z2WmHs-gpae8pxdZKM5BMFbte_tvh83Jv5MOVuyY0+Lvg@mail.gmail.com> <CAEKnhAF5yoO671XMa-1XE1=2UYBCtTjUcHp5cF8s_zLeS1enxw@mail.gmail.com>
Date: Mon, 30 Jan 2017 16:54:17 -0500
Message-ID: <CAKws9z1=+3si73ALF1k_oMgjaqiCiMTyusF7y_Jmb26OkDWERA@mail.gmail.com>
To: Jakub Zelenka <bukka@php.net>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113ce6ba76198a054756db59
Subject: Re: [PHP-DEV] [RFC] libsodium (PHP 7.2)
From: scott@paragonie.com (Scott Arciszewski)

--001a113ce6ba76198a054756db59
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 30, 2017 at 4:37 PM, Jakub Zelenka <bukka@php.net> wrote:

> On Mon, Jan 30, 2017 at 7:40 PM, Scott Arciszewski <scott@paragonie.com>
> wrote:
>
>>
>> On Sun, Jan 29, 2017 at 2:04 PM, Jakub Zelenka <bukka@php.net> wrote:
>>
>>> Hi,
>>>
>>> On Wed, Jan 11, 2017 at 6:22 PM, Scott Arciszewski <scott@paragonie.com=
>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I'm resurrecting my RFC to add libsodium as a core extension to PHP 7.=
2.
>>>>
>>>>
>>> I'm still not sure why it needs to be in the core. As I said before,
>>> there are lots of healthy extension that are not in the core and it
>>> certainly doesn't make them less used (e.g. redis, xdebug or mongo driv=
er).
>>> At the end it's all about packaging...
>>>
>>> I think libsodium has lots of really good features and it's a very nice
>>> lib. However what makes me a bit uneasy about libsodium is that it's
>>> basically a one dev library which is even clearly visible in here:
>>>
>>> https://github.com/jedisct1/libsodium/graphs/contributors
>>>
>>> It is certainly a bit more risky to support such lib if it all depends
>>> on on one person rather than a team of developers. I'm not saying that =
it's
>>> the same but mcrypt used to be also just one developer lib...
>>>
>>> Cheers
>>>
>>> Jakub
>>>
>>
>> =E2=80=8BI erroneously replied off-list, and rather than forward message=
s that
>> were sent directly to me (on the offchance that they were not intended t=
o
>> be public), I'll just reiterate what I said privately. From my original
>> email:
>>
>>
> I thought that it might have been meant to be sent publicly before so wil=
l
> reply publicly again :)
>
>
>> > =E2=80=8BWas mcrypt in core?
>> >
>>
>
> Yes and it was a mistake IMO (however it might have been a good idea at
> the time it was added as I have no idea how it was with out of core
> extensions at that time...)
>
>
>> > Is openssl still in core?=E2=80=8B
>> >
>>
>
> Yes but in this case we need to consider also the TLS part that is linked
> and required by other core (stream) parts so there is actually important
> point to have it in the core.
>
>
>> > If the answer to both these questions is "Yes", then it follows that
>> libsodium should be in the core. Especially if everyone agrees that it
>> should be included by default.
>> >
>>
>
> No it does not follow. Both extensions were added long time ago probably
> for various reasons valid at that time but currently there is no need to
> add new extension unless there is a some technical reason why it should b=
e
> in the core (e.g. dependency of other extension or some direct hooking to
> the core parts).
>
>
>> > > =E2=80=8B=E2=80=8BHowever what makes me a bit uneasy about libsodium=
 is that it's
>> basically a one dev library which is even clearly visible in here:=E2=80=
=8B
>> >
>> > You're looking at it all wrong. Look here instead:
>> https://github.com/jedisct1/libsodium/blob/master/AUTHORS
>> >
>> > The person who checked the code into Github may have been Frank Denis
>> for a lot of cases, but the code itself was written by cryptographers.
>> >
>> > Calling it "basically a one dev library" sounds simultaneously
>> dismissive and misinformed.=E2=80=8B (Also: There have been 58 contribut=
ors besides
>> Frank, which doesn't lead to your point at all.)
>> >
>>
>
> I'm aware that the algorithms are taken from the public domain
> implementations done by cryptographers and there are some other
> contributions. What I mean by one dev lib is that there is just one
> developer that maintains it which means for example regularly commit to t=
he
> extension, handles security issues and doing releases of the lib (I shoul=
d
> have maybe said one maintainer lib). Basically what I want to say is what
> happens if Frank is not able to continue development of the library for
> some reason. That raises chance that the library might become not
> maintained which is more probable than with a team of developers
> maintaining the lib.
>
>
>> > Do you know any cryptography experts? Go ask them, "What would you
>> rather see devs use? OpenSSL or libsodium?" and report back what they sa=
y.
>> To be clear: I'm fairly confident that a large majority will not choose
>> OpenSSL.=E2=80=8B
>>
>
> There is nothing that should prevent anyone to use LIbsodium if it's not
> in the core. You can see examples of the other popular extensions that ar=
e
> not in the core and are used heavily.
>
>
>> Furthermore, I'd like to raise an additional point.
>>
>> PHP Archive signing currently has the following options:
>>
>> - A hash function (forgery =3D trivial)
>> - OpenSSL signing (which I believe means RSA-PKCSv1.5 with SHA1; Daniel
>> Bleichenbacher had something to say about that in 2006, but e=3D65537 br=
eaks
>> the public exploit)
>>
>> Putting libsodium in core allows us to add Ed25519 signatures to Phars,
>> which means that we can provide a reasonable level (128 bits is what I c=
all
>> reasonable) of assurance that the PHP archive is authentic (assuming you
>> have a trustworthy public key).
>>
>>
> So finally some technical reason why it would be useful to have it in the
> core. :) It would be really good to add this and possible some other use
> cases (if you can come up with) to the RFC for example as a future scope.
>
>
>> Without putting libsodium in core, can we do that? If not, that's a soli=
d
>> motivation to vote YES on this RFC.
>>
>> Conversely, let's discuss a hypothetical: If this motion is abandoned,
>> can you (or, rather, everyone on this mailing list working together)
>> guarantee that 100% of operating systems will bundle libsodium and the P=
HP
>> extension in PECL with PHP 7.2 out-of-the-box, by default? That includes
>> Windows, FreeBSD, OpenBSD, Debian, Ubuntu, RedHat, CentOS, and even obsc=
ure
>> Unix-like academic projects. 100% coverage. Not 99%. Not 50%. Exactly 10=
0%.
>>
>>
> Ok I see another point which is improving adoption of libsodium in the
> distros. Basically sending a signal that we want to have it packaged whic=
h
> is another thing that could be added to the RFC to make a bit more clear.
> I'm not 100% sure if it's something that PHP should do but it's a good
> point anyway.
>
>
>> If we can't guarantee 100% adoption without putting libsodium in the
>> core, given the current political climate[1] and the history of unlawful
>> cryptography export restriction enforcement[2], I'd fear that OSes
>> (especially Enterprise Linux distributions that hold government contract=
s)
>> could be pressured against offering secure cryptography (i.e. libsodium)=
 in
>> future versions of PHP. If we make it a core extension, it's included
>> unless you go out of the way to compile PHP without it. This means bette=
r
>> security by default.
>>
>> Let's be clear: Libsodium one of the highest regarded libraries that
>> exposes very well-studied cryptography primitives (RFC 7748, RFC 8032, R=
FC
>> 7693, etc.) with a misuse-resistant interface. It's also extremely
>> permissively licensed (ISC).
>>
>> If Frank Denis were to get hit by a bus tomorrow, anyone could pick it u=
p
>> and continue his work. I wouldn't advise blindly trusting anyone who for=
ks
>> it, but the cryptography community would likely certainly come together =
and
>> suggest which fork is most trustworthy. If nothing else, you could count=
 on
>> the cryptographers whose work is bundled in libsodium to recommend a for=
k.
>> The bus factor, while a legitimate concern, isn't going to be a source o=
f
>> liability for libsodium nor for PHP.
>>
>> [1]: https://web.archive.org/web/20170127070926/https://www.
>> cnet.com/news/trump-apple-boycott-terrorist-iphone-san-bernardino-fbi/
>> [2]: https://en.wikipedia.org/wiki/Bernstein_v._United_States
>>
>>
> Thanks for bringing up some good points!
>
> Cheers
>
> Jakub
>
>
=E2=80=8BI will update the RFC as suggested.

Thank you!

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>=E2=80=8B

--001a113ce6ba76198a054756db59--