Everything

php

[RFC] Libsodium (bump)

php.internals

Scott Arciszewski

10 years ago

Link to RFC: https://wiki.php.net/rfc/libsodium

I'd like to bump the RFC to make Libsodium a core extension, as per
Ferenc's suggestion on the mcrypt RFC.

Question: If this extension is adopted, which syntax would you prefer?

\Sodium\func()
Sodium::func()
sodium_func()

As it currently stands, the PHP extension in PECL uses a namespace +
function format.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>

Fleshgrinder

10 years ago

On 3/15/2016 6:40 PM, Scott Arciszewski wrote:

> Link to RFC: https://wiki.php.net/rfc/libsodium
>
> I'd like to bump the RFC to make Libsodium a core extension, as per
> Ferenc's suggestion on the mcrypt RFC.
>
> Question: If this extension is adopted, which syntax would you prefer?
>
>     \Sodium\func()
>     Sodium::func()
>     sodium_func()
>
> As it currently stands, the PHP extension in PECL uses a namespace +
> function format.
>
> Scott Arciszewski
> Chief Development Officer
> Paragon Initiative Enterprises <https://paragonie.com>
>

The third option (*sodium_func()*) as per coding standard:

https://github.com/php/php-src/blob/master/CODING_STANDARDS#L110-L125

I do not think that it makes sense to provide a static class for this
functionality, correct me if I am wrong.

It definitely makes no sense to namespace the stuff if you want it in
core and it violate the coding standards (for a good reason).

--
Richard "Fleshgrinder" Fussenegger

Scott Arciszewski

10 years ago

On Tue, Mar 15, 2016 at 1:59 PM, Fleshgrinder <php@fleshgrinder.com> wrote:

> On 3/15/2016 6:40 PM, Scott Arciszewski wrote:
> > Link to RFC: https://wiki.php.net/rfc/libsodium
> >
> > I'd like to bump the RFC to make Libsodium a core extension, as per
> > Ferenc's suggestion on the mcrypt RFC.
> >
> > Question: If this extension is adopted, which syntax would you prefer?
> >
> >     \Sodium\func()
> >     Sodium::func()
> >     sodium_func()
> >
> > As it currently stands, the PHP extension in PECL uses a namespace +
> > function format.
> >
> > Scott Arciszewski
> > Chief Development Officer
> > Paragon Initiative Enterprises <https://paragonie.com>
> >
>
> The third option (*sodium_func()*) as per coding standard:
>
> https://github.com/php/php-src/blob/master/CODING_STANDARDS#L110-L125
>
> I do not think that it makes sense to provide a static class for this
> functionality, correct me if I am wrong.
>
> It definitely makes no sense to namespace the stuff if you want it in
> core and it violate the coding standards (for a good reason).
>
> --
> Richard "Fleshgrinder" Fussenegger
>
>

​Okay, I missed that detail somehow.​

​I talked with Frank and the current plan of action as I understand it is:

1. Finish libsodium 1.0.9
2. Finish libsodium-php 1.0.3
3. Create a branch for this RFC that conforms to the coding standards
4. If the RFC passes, send a pull request to add the standards-conforming
version of the sodium PHP extension to core

I'll hold off on opening the vote until there's something concrete and
meaningful for everyone to test.

Are there any other concerns, questions, comments, etc. that haven't
already been addressed in the previous thread?
​
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>​

Yasuo Ohgaki

10 years ago

Hi Scott,

On Wed, Mar 16, 2016 at 2:40 AM, Scott Arciszewski <scott@paragonie.com> wrote:

> Question: If this extension is adopted, which syntax would you prefer?
>
>     \Sodium\func()
>     Sodium::func()
>     sodium_func()

I prefer both of

Sodium::func()
sodium_func()

IMO, we are better to provide both OO and procedural API which have
identical features. i.e. I prefer multi paradigm programming language.
It would be natural for PHP since PHP was born as procedural language
and evolving as OO.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Fleshgrinder

10 years ago

On 3/15/2016 11:02 PM, Yasuo Ohgaki wrote:

> Hi Scott,
>
> On Wed, Mar 16, 2016 at 2:40 AM, Scott Arciszewski <scott@paragonie.com> wrote:
>> Question: If this extension is adopted, which syntax would you prefer?
>>
>>     \Sodium\func()
>>     Sodium::func()
>>     sodium_func()
>
> I prefer both of
>
>      Sodium::func()
>      sodium_func()
>
> IMO, we are better to provide both OO and procedural API which have
> identical features. i.e. I prefer multi paradigm programming language.
> It would be natural for PHP since PHP was born as procedural language
> and evolving as OO.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>

Providing both only makes sense if you receive an object on which you
can perform more operations. It is a different situation if everything
that the extension provides is always a function in a mathematical sense
(same input produces single output). I love multi-paradigm languages but
that does not mean that everything needs to provide every paradigm; you
actually end up with a mess in such cases. We have good examples where
it makes sense [1] and bad examples where it makes no sense [2] together
in a single extension. The major reason to provide an object is to
encapsulate some information and/or state that you can pass around
(dependency injection) and that has some kind of behavior. This is most
certainly not the case in [2] because it consists only of previously
mentioned mathematical functions. [1] is different, it can be passed
around, preconfigured with some state (a specific locale and pattern).
It would become even more useful if one could instantiate it only with a
locale and pass it around, prepared to handle multiple patterns; but
that's another story.

[1] https://secure.php.net/class.messageformatter
[2] https://secure.php.net/class.locale

TL;DR Providing Ext::fn() and ext_fn() for everything only creates a
mess. Decide on one way and decide on the way that makes sense.
Multi-paradigm does not mean "provide/use everything, always" it means
"provide/use one paradigm as it make senses from multiple ones"; that is
also where it takes its strength from.

--
Richard "Fleshgrinder" Fussenegger

Yasuo Ohgaki

10 years ago

Hi all,

On Thu, Mar 17, 2016 at 2:57 AM, Fleshgrinder <php@fleshgrinder.com> wrote:

> On 3/15/2016 11:02 PM, Yasuo Ohgaki wrote:
>> Hi Scott,
>>
>> On Wed, Mar 16, 2016 at 2:40 AM, Scott Arciszewski <scott@paragonie.com> wrote:
>>> Question: If this extension is adopted, which syntax would you prefer?
>>>
>>>     \Sodium\func()
>>>     Sodium::func()
>>>     sodium_func()
>>
>> I prefer both of
>>
>>      Sodium::func()
>>      sodium_func()
>>
>> IMO, we are better to provide both OO and procedural API which have
>> identical features. i.e. I prefer multi paradigm programming language.
>> It would be natural for PHP since PHP was born as procedural language
>> and evolving as OO.
>>
>> Regards,
>>
>> --
>> Yasuo Ohgaki
>> yohgaki@ohgaki.net
>>
>
> Providing both only makes sense if you receive an object on which you
> can perform more operations. It is a different situation if everything
> that the extension provides is always a function in a mathematical sense
> (same input produces single output). I love multi-paradigm languages but
> that does not mean that everything needs to provide every paradigm; you
> actually end up with a mess in such cases. We have good examples where
> it makes sense [1] and bad examples where it makes no sense [2] together
> in a single extension. The major reason to provide an object is to
> encapsulate some information and/or state that you can pass around
> (dependency injection) and that has some kind of behavior. This is most
> certainly not the case in [2] because it consists only of previously
> mentioned mathematical functions. [1] is different, it can be passed
> around, preconfigured with some state (a specific locale and pattern).
> It would become even more useful if one could instantiate it only with a
> locale and pass it around, prepared to handle multiple patterns; but
> that's another story.
>
> [1] https://secure.php.net/class.messageformatter
> [2] https://secure.php.net/class.locale
>
> TL;DR Providing Ext::fn() and ext_fn() for everything only creates a
> mess. Decide on one way and decide on the way that makes sense.
> Multi-paradigm does not mean "provide/use everything, always" it means
> "provide/use one paradigm as it make senses from multiple ones"; that is
> also where it takes its strength from.

Sounds good to me, too. We may consider more carefully. Current
namespaced names may be the best option.

The only problem with this is "It looks inconsistent with existing
module functions". We may consider how we are going to use namespaces
for extensions in general. I like the idea

\ModuleName\function_name

for all extension functions, indeed.

Question is whether we should use something like
"\PHP\ModuleName\function_name" or "\ModuleName\function_name". I'm
not sure which one is better in the long run.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Fleshgrinder

10 years ago

On 3/17/2016 4:04 AM, Yasuo Ohgaki wrote:

> The only problem with this is "It looks inconsistent with existing
> module functions". We may consider how we are going to use namespaces
> for extensions in general. I like the idea
>
> \ModuleName\function_name
>
> for all extension functions, indeed.
>
> Question is whether we should use something like
> "\PHP\ModuleName\function_name" or "\ModuleName\function_name". I'm
> not sure which one is better in the long run.
>
>

I think that this is not necessary. The existing system does not seem to
pose any problems, changing the coding standard now only creates a
mixture. There are still many extension who are not even in conformance
with the coding standard and such a change would make it even worse.
Let's first try to clean things up; which is already a super hard task
because many people are completely against, as we've seen it in the
*var* deprecation thread.

That being said, *\PHP\ModuleName\function_name* is a very bad choice
for multiple reasons:

1. PHP already has its reserved namespace, the global one *\*.
2. Is it *\PHP* or *\Php*? This opens a huge can of worms.

And even if it is *\ModuleName\function_name*:

3. The amount of *use* statements will explode and the situation becomes
equal to the one we had in the past with the millions of
*require(_once)* lines in the preamble of each file. It requires more
management on the userland side.

TL;DR the current system works just fine so why change? Just because it
is sexy right now? Will it be sexy in 10 years?

--
Richard "Fleshgrinder" Fussenegger

Levi Morrison

10 years ago

> 1. PHP already has its reserved namespace, the global one *\*.
> 2. Is it *\PHP* or *\Php*? This opens a huge can of worms.

We've technically only reserved PHP and php but it is case insensitive
anyway. PHP *does not* reserve the global namespace. At least that's
not what it says in the docs.

Levi Morrison

10 years ago

> At least that's not what it says in the docs.

I  meant: at least according to the docs:
http://php.net/manual/en/language.namespaces.rationale.php

Fleshgrinder

10 years ago

On 3/18/2016 9:56 PM, Levi Morrison wrote:

>> At least that's not what it says in the docs.
>
> I  meant: at least according to the docs:
> http://php.net/manual/en/language.namespaces.rationale.php
>
>> Namespace names PHP and php, and compound names starting with these names (like PHP\Classes) are reserved for internal language use and should not be used in the userspace code.
>

Okay, I did not know that. However, right now all internal classes and
functions are in *\* and that is also what the coding standards
prescribe. My point being (and was) that this system works well, so why
change it now shortly after a new major version. Changing all old code
would result in an unbelievable breaking change, even with a new major
version, without any real value. Yes, I am saying that although I am
usually totally in favor of changing things to the better. I simply do
not see *any* benefit here.

--
Richard "Fleshgrinder" Fussenegger

Scott Arciszewski

10 years ago

On Sat, Mar 19, 2016 at 4:30 AM, Fleshgrinder <php@fleshgrinder.com> wrote:

> On 3/18/2016 9:56 PM, Levi Morrison wrote:
> >> At least that's not what it says in the docs.
> >
> > I  meant: at least according to the docs:
> > http://php.net/manual/en/language.namespaces.rationale.php
> >
> >> Namespace names PHP and php, and compound names starting with these
> names (like PHP\Classes) are reserved for internal language use and should
> not be used in the userspace code.
> >
>
> Okay, I did not know that. However, right now all internal classes and
> functions are in *\* and that is also what the coding standards
> prescribe. My point being (and was) that this system works well, so why
> change it now shortly after a new major version. Changing all old code
> would result in an unbelievable breaking change, even with a new major
> version, without any real value. Yes, I am saying that although I am
> usually totally in favor of changing things to the better. I simply do
> not see *any* benefit here.
>
> --
> Richard "Fleshgrinder" Fussenegger
>
>

I'm 99% sure that the plan is to go with sodium_* since the change isn't
/that/ painful. (Creating a polyfill for code written against the PHP
extension is trivial.)

While I'd love to break new ground with this (the first extension to
actually use the reserved namespace), I'm concerned this would just create
a lot of pointless bikeshedding arguments. The goal here isn't to be
totally avant garde and break exciting new ground (even if the plot is
already allocated for "future development").

The goal here (for me, anyway) is to make cryptography in PHP boring: It
should be simply secure (with a security level >= 2^100 bits for all
meaningful metrics), as side-channel resistant as possible, and intuitive
for non-cryptographers to use properly. I want to see PHP get to where it's
easier to do the secure thing than to do the insecure thing. The password
hashing API in 5.5 was the first great leap towards this goal. Adding
CSPRNG functions in PHP 7 that throws an Exception when PHP can't access
the kernel's CSPRNG moved us further in the right direction.

Deprecating libmcrypt and introducing libsodium is, to me, the next logical
step towards that goal.

Until that happens, PHP developers will be given more than enough rope to
hang themselves (and the company they work for) with their fumbled
cryptography engineering. Let's take away the noose and give everyone a
safety net.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>​

Yasuo Ohgaki

10 years ago

Hi Levi,

On Sat, Mar 19, 2016 at 5:56 AM, Levi Morrison <levim@php.net> wrote:

>> At least that's not what it says in the docs.
>
> I  meant: at least according to the docs:
> http://php.net/manual/en/language.namespaces.rationale.php
>
>> Namespace names PHP and php, and compound names starting with these names (like PHP\Classes) are reserved for internal language use and should not be used in the userspace code.

Question would be "When and How we are going to use it?"
Putting everything under \PHP namespace  would be nice in general. We
can provide compatible APIs under \PHP. e.g. \PHP\7_0 may be PHP 7.0
compatible APIs for PHP 8.0, etc. It makes upgrading and version up
easier if this is done.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

David Zuelke

10 years ago

I think I've said this before; please call it ext-sodium, not ext-libsodium.

David

Scott Arciszewski

10 years ago

Noted and agreed.
On Mar 15, 2016 9:56 PM, "David Zuelke" <dz@heroku.com> wrote: