# [RFC] Libsodium (bump) - Thread: https://externals.io/message/91678 - Original archive: https://news-web.php.net/php.internals/91678 - Started by Scott Arciszewski on 2016-03-15T17:40:12+00:00 - Messages: 14 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #91678 — Scott Arciszewski — 2016-03-15T17:40:12+00:00 URL: https://externals.io/message/91678#91678 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 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 > 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 --- ## #91682 — Scott Arciszewski — 2016-03-15T18:17:38+00:00 URL: https://externals.io/message/91678#91682 · In reply to: #91681 > > > […] > > 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 ​ --- ## #91684 — Yasuo Ohgaki — 2016-03-15T22:02:33+00:00 URL: https://externals.io/message/91678#91684 · In reply to: #91678 Hi Scott, > 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 --- ## #91688 — David Zuelke — 2016-03-16T01:56:14+00:00 URL: https://externals.io/message/91678#91688 · In reply to: #91678 I think I've said this before; please call it ext-sodium, not ext-libsodium. David > > > 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 I think I've said this before; please call it ext-sodium, not > ext-libsodium. > > David > > > > […] --- ## #91702 — Fleshgrinder — 2016-03-16T17:57:43+00:00 URL: https://externals.io/message/91678#91702 · In reply to: #91684 > Hi Scott, > > > > […] > > 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 --- ## #91727 — Yasuo Ohgaki — 2016-03-17T03:04:37+00:00 URL: https://externals.io/message/91678#91727 · In reply to: #91702 Hi all, > > > […] > > 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 --- ## #91751 — Fleshgrinder — 2016-03-18T20:03:14+00:00 URL: https://externals.io/message/91678#91751 · In reply to: #91727 > 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 --- ## #91755 — Levi Morrison — 2016-03-18T20:53:33+00:00 URL: https://externals.io/message/91678#91755 · In reply to: #91751 > 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. --- ## #91756 — Levi Morrison — 2016-03-18T20:56:46+00:00 URL: https://externals.io/message/91678#91756 · In reply to: #91755 > 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. --- ## #91762 — Fleshgrinder — 2016-03-19T08:30:52+00:00 URL: https://externals.io/message/91678#91762 · In reply to: #91756 > > […] > > I meant: at least according to the docs: > http://php.net/manual/en/language.namespaces.rationale.php > > > […] > 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 --- ## #91788 — Scott Arciszewski — 2016-03-20T16:55:04+00:00 URL: https://externals.io/message/91678#91788 · In reply to: #91762 > > > […] > 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 ​ --- ## #94908 — Yasuo Ohgaki — 2016-08-07T23:36:47+00:00 URL: https://externals.io/message/91678#94908 · In reply to: #91756 Hi Levi, > > […] > > I meant: at least according to the docs: > http://php.net/manual/en/language.namespaces.rationale.php > > > […] 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