Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] [VOTE] Libsodium as a core extension in PHP 7.2 »

[RFC] [VOTE] Libsodium as a core extension in PHP 7.2

php.internals

Scott Arciszewski

9 years ago
I've opened the vote for the libsodium RFC. https://wiki.php.net/rfc/libsodium See https://externals.io/thread/626 for the previous discussion topics. The vote closes at 21:00 UTC (4 PM Eastern Time) next Friday. Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises <https://paragonie.com>

Yasuo Ohgaki

9 years ago
Hi Scott and all, On Sat, Feb 4, 2017 at 5:44 AM, Scott Arciszewski <scott@paragonie.com> wrote:
> I've opened the vote for the libsodium RFC. > > https://wiki.php.net/rfc/libsodium > > See https://externals.io/thread/626 for the previous discussion topics. > > The vote closes at 21:00 UTC (4 PM Eastern Time) next Friday. >
I voted for "No, sodium_foo" syntax in order to be consistent with existing procedural APIs. 2/3 majority wouldn't fit nicely. What it would be if vote result is 51% vs 49%? More than half is good enough for 2nd vote choice. IMO. Regards,
-- Yasuo Ohgaki yohgaki@ohgaki.net

Scott Arciszewski

9 years ago
On Fri, Feb 3, 2017 at 6:19 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> Hi Scott and all, > > On Sat, Feb 4, 2017 at 5:44 AM, Scott Arciszewski <scott@paragonie.com> > wrote: > >> I've opened the vote for the libsodium RFC. >> >> https://wiki.php.net/rfc/libsodium >> >> See https://externals.io/thread/626 for the previous discussion topics. >> >> The vote closes at 21:00 UTC (4 PM Eastern Time) next Friday. >> > > I voted for "No, sodium_foo" syntax in order to be consistent with > existing procedural APIs. > 2/3 majority wouldn't fit nicely. What it would be if vote result is 51% > vs 49%? > More than half is good enough for 2nd vote choice. IMO. > > Regards, > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net > >
I like \Sodium\foo instead of sodium_foo, but it deviates from the norm.​ ​ If we're going to break the norm, we should do so on a stronger majority than 50%+1. Also, I thought the rules changed so *_everything_* needed 2/3 now?​ ​ Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises <https://paragonie.com/> ​

Nikita Popov

9 years ago
On Sat, Feb 4, 2017 at 12:54 AM, Scott Arciszewski <scott@paragonie.com> wrote:
> On Fri, Feb 3, 2017 at 6:19 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: > > > Hi Scott and all, > > > > On Sat, Feb 4, 2017 at 5:44 AM, Scott Arciszewski <scott@paragonie.com> > > wrote: > > > >> I've opened the vote for the libsodium RFC. > >> > >> https://wiki.php.net/rfc/libsodium > >> > >> See https://externals.io/thread/626 for the previous discussion topics. > >> > >> The vote closes at 21:00 UTC (4 PM Eastern Time) next Friday. > >> > > > > I voted for "No, sodium_foo" syntax in order to be consistent with > > existing procedural APIs. > > 2/3 majority wouldn't fit nicely. What it would be if vote result is 51% > > vs 49%? > > More than half is good enough for 2nd vote choice. IMO. > > > > Regards, > > > > -- > > Yasuo Ohgaki > > yohgaki@ohgaki.net > > > > > I like \Sodium\foo instead of sodium_foo, but it deviates from the norm.​ > ​ If we're going to break the norm, we should do so on a stronger majority > than 50%+1. > > Also, I thought the rules changed so *_everything_* needed 2/3 now?​ >
The usual rule is that "secondary" votes use 50% majority, to avoid bias in one direction or the other. Regards, Nikita

Alex Bowers

9 years ago
On 4 February 2017 at 00:04, Nikita Popov <nikita.ppv@gmail.com> wrote:
> On Sat, Feb 4, 2017 at 12:54 AM, Scott Arciszewski <scott@paragonie.com> > wrote: > > > On Fri, Feb 3, 2017 at 6:19 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: > > > > > Hi Scott and all, > > > > > > On Sat, Feb 4, 2017 at 5:44 AM, Scott Arciszewski <scott@paragonie.com > > > > > wrote: > > > > > >> I've opened the vote for the libsodium RFC. > > >> > > >> https://wiki.php.net/rfc/libsodium > > >> > > >> See https://externals.io/thread/626 for the previous discussion > topics. > > >> > > >> The vote closes at 21:00 UTC (4 PM Eastern Time) next Friday. > > >> > > > > > > I voted for "No, sodium_foo" syntax in order to be consistent with > > > existing procedural APIs. > > > 2/3 majority wouldn't fit nicely. What it would be if vote result is > 51% > > > vs 49%? > > > More than half is good enough for 2nd vote choice. IMO. > > > > > > Regards, > > > > > > -- > > > Yasuo Ohgaki > > > yohgaki@ohgaki.net > > > > > > > > I like \Sodium\foo instead of sodium_foo, but it deviates from the norm.​ > > ​ If we're going to break the norm, we should do so on a stronger > majority > > than 50%+1. > > > > Also, I thought the rules changed so *_everything_* needed 2/3 now?​ > > > > The usual rule is that "secondary" votes use 50% majority, to avoid bias in > one direction or the other. > > Regards, > Nikita >
Would it not be possible for _both_ to be supported? It would be just an alias

Yasuo Ohgaki

9 years ago
On Sat, Feb 4, 2017 at 10:22 AM, Alex Bowers <bowersbros@gmail.com> wrote:
> Would it not be possible for _both_ to be supported? It would be just an > alias
I would vote for this!! Regards,
-- Yasuo Ohgaki yohgaki@ohgaki.net

Niklas Keller

9 years ago
> > Would it not be possible for _both_ to be supported? It would be just an > alias >
What's the benefit? I can just see bloat and confusion.

Fleshgrinder

9 years ago
On 2/4/2017 12:54 AM, Scott Arciszewski wrote:
> I like \Sodium\foo instead of sodium_foo, but it deviates from the norm.​ > ​ If we're going to break the norm, we should do so on a stronger majority > than 50%+1. >
I see another problem besides the issue that a namespaced core elements are being introduced like in the US Senate, hidden within another bill, and the fact that I still don't like the Sodium API itself and that is that this might make autoloader updates in the future in regards to functions and/or constants more complicated. One idea back than was that the autoloader is only triggered for things that are listed in a use statement. This would have multiple advantages since we would not require any backslash in front of built-in stuff anymore as anything that is not within a use would never trigger the autoloader and remove any potential performance hit for built-in stuff due to autoloading. Sodium having its own namespace would definitely appear in use statements because that is how IDEs work today and because nobody wants to write `Sodium\foo()`, or do they?
-- Richard "Fleshgrinder" Fussenegger

Scott Arciszewski

9 years ago
On Sat, Feb 4, 2017 at 5:37 AM, Fleshgrinder <php@fleshgrinder.com> wrote:
> > On 2/4/2017 12:54 AM, Scott Arciszewski wrote: > > I like \Sodium\foo instead of sodium_foo, but it deviates from the norm. > > If we're going to break the norm, we should do so on a stronger majority > > than 50%+1. > > > > I see another problem besides the issue that a namespaced core elements > are being introduced like in the US Senate, hidden within another bill, > and the fact that I still don't like the Sodium API itself and that is > that this might make autoloader updates in the future in regards to > functions and/or constants more complicated. > > One idea back than was that the autoloader is only triggered for things > that are listed in a use statement. This would have multiple advantages > since we would not require any backslash in front of built-in stuff > anymore as anything that is not within a use would never trigger the > autoloader and remove any potential performance hit for built-in stuff > due to autoloading. > > Sodium having its own namespace would definitely appear in use > statements because that is how IDEs work today and because nobody wants > to write `Sodium\foo()`, or do they? > > -- > Richard "Fleshgrinder" Fussenegger
Hi,
> I see another problem besides the issue that a namespaced core elements > are being introduced like in the US Senate, hidden within another bill,
This is a separate choice that people can vote for. It's not exactly hidden; nor is it bundled into a single "Yes/No". The vote option concerns "permit an exception to the coding style" not "change the coding style for everything". If anyone playing at home wants to propose a separate RFC to update the coding style to allow the use of namespaced functions in all future RFCs, it looks like (at present count) at least 7 people would find such a proposal amicable. (8 if you count me, though I don't have vote karma so my opinion is irrelevant.) Regards, Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises <https://paragonie.com>

Fleshgrinder

9 years ago
On 2/4/2017 4:20 PM, Scott Arciszewski wrote:
> Hi, > > This is a separate choice that people can vote for. It's not exactly > hidden; nor is it bundled into a single "Yes/No". > > The vote option concerns "permit an exception to the coding style" not > "change the coding style for everything". If anyone playing at home > wants to propose a separate RFC to update the coding style to allow > the use of namespaced functions in all future RFCs, it looks like (at > present count) at least 7 people would find such a proposal amicable. > (8 if you count me, though I don't have vote karma so my opinion is > irrelevant.) > > Regards, > > Scott Arciszewski > Chief Development Officer > Paragon Initiative Enterprises <https://paragonie.com> >
Hey :) Oh don't get me wrong here, I have no problem with namespaced core stuff in general and I'd probably vote yes myself. The issue here is that it might (!) be that some of the people who actually can vote do not participate in the vote because they think "oh well, sodium sounds like an RFC I'm not interested in I'll let the others vote" and in reality the results change a thing that was the same since the inception of PHP. This is what I wanted to express with the comparison to the US Senate. ;)
-- Richard "Fleshgrinder" Fussenegger

Stephen Reay

9 years ago
Hi Scott, (Sorry for re-send)
> On 4 Feb 2017, at 22:20, Scott Arciszewski <scott@paragonie.com> wrote: > > On Sat, Feb 4, 2017 at 5:37 AM, Fleshgrinder <php@fleshgrinder.com> wrote: >> >> On 2/4/2017 12:54 AM, Scott Arciszewski wrote: >>> I like \Sodium\foo instead of sodium_foo, but it deviates from the norm. >>> If we're going to break the norm, we should do so on a stronger majority >>> than 50%+1. >>> >> >> I see another problem besides the issue that a namespaced core elements >> are being introduced like in the US Senate, hidden within another bill, >> and the fact that I still don't like the Sodium API itself and that is >> that this might make autoloader updates in the future in regards to >> functions and/or constants more complicated. >> >> One idea back than was that the autoloader is only triggered for things >> that are listed in a use statement. This would have multiple advantages >> since we would not require any backslash in front of built-in stuff >> anymore as anything that is not within a use would never trigger the >> autoloader and remove any potential performance hit for built-in stuff >> due to autoloading. >> >> Sodium having its own namespace would definitely appear in use >> statements because that is how IDEs work today and because nobody wants >> to write `Sodium\foo()`, or do they? >> >> -- >> Richard "Fleshgrinder" Fussenegger > > Hi, > >> I see another problem besides the issue that a namespaced core elements >> are being introduced like in the US Senate, hidden within another bill, > > This is a separate choice that people can vote for. It's not exactly > hidden; nor is it bundled into a single "Yes/No". > > The vote option concerns "permit an exception to the coding style" not > "change the coding style for everything". If anyone playing at home > wants to propose a separate RFC to update the coding style to allow > the use of namespaced functions in all future RFCs, it looks like (at > present count) at least 7 people would find such a proposal amicable. > (8 if you count me, though I don't have vote karma so my opinion is > irrelevant.) > > Regards, > > Scott Arciszewski > Chief Development Officer > Paragon Initiative Enterprises <https://paragonie.com> > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php
I’m not a fan of the use of namespaced functions in the core either. Given that 2/3 is required to accept a change, wouldn’t it make more sense for the ‘default’ on Q2 be to follow PHP existing standards, and require the 2/3 majority to deviate from that? Cheers Stephen

Nikita Popov

9 years ago
On Fri, Feb 3, 2017 at 9:44 PM, Scott Arciszewski <scott@paragonie.com> wrote:
> I've opened the vote for the libsodium RFC. > > https://wiki.php.net/rfc/libsodium > > See https://externals.io/thread/626 for the previous discussion topics. > > The vote closes at 21:00 UTC (4 PM Eastern Time) next Friday. >
I just took a very quick look at the extension source. One question: Right now it throws recoverable fatal errors all over the place. Why doesn't it use exceptions instead? We replaced (to the most part) use of recoverable fatals with exceptions in PHP 7 and reintroducing them in this quantity would be highly dubious to me. Also a question on maintenance: If this extension is bundled, will the source compatibility with PHP 5 be removed, or do you plan on keeping a single code-base for the bundled extension and PECL, with support for PHP 5? None of the current bundled extensions do this, as it is a significant maintenance burden. Thanks, Nikita

Scott Arciszewski

9 years ago
On Sat, Feb 4, 2017 at 11:16 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> On Fri, Feb 3, 2017 at 9:44 PM, Scott Arciszewski <scott@paragonie.com> > wrote: >> >> I've opened the vote for the libsodium RFC. >> >> https://wiki.php.net/rfc/libsodium >> >> See https://externals.io/thread/626 for the previous discussion topics. >> >> The vote closes at 21:00 UTC (4 PM Eastern Time) next Friday. > > > I just took a very quick look at the extension source. One question: Right > now it throws recoverable fatal errors all over the place. Why doesn't it > use exceptions instead? We replaced (to the most part) use of recoverable > fatals with exceptions in PHP 7 and reintroducing them in this quantity > would be highly dubious to me. > > Also a question on maintenance: If this extension is bundled, will the > source compatibility with PHP 5 be removed, or do you plan on keeping a > single code-base for the bundled extension and PECL, with support for PHP 5? > None of the current bundled extensions do this, as it is a significant > maintenance burden. > > Thanks, > Nikita
Hi Nikita,
> I just took a very quick look at the extension source. One question: Right > now it throws recoverable fatal errors all over the place. Why doesn't it > use exceptions instead? We replaced (to the most part) use of recoverable > fatals with exceptions in PHP 7 and reintroducing them in this quantity > would be highly dubious to me.
I don't know why it doesn't (my guess: that part of the code simply wasn't updated); but if we include libsodium in 7.2, I'd definitely switch everything to use exceptions instead of fatal errors, for exactly the same reasons laid out in the discussion over random_* throwing exceptions in 7.0.
> Also a question on maintenance: If this extension is bundled, will the > source compatibility with PHP 5 be removed, or do you plan on keeping a > single code-base for the bundled extension and PECL, with support for PHP 5? > None of the current bundled extensions do this, as it is a significant > maintenance burden.
Definitely drop PHP 5 support in the extension that is bundled with PHP 7.2 (although the PECL extension can keep it), Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises <https://paragonie.com>