Re: [PHP-DEV] [RFC] [PHP 7.1] libsodium
Hi Scott,
On Thu, May 21, 2015 at 10:15 AM, Scott Arciszewski sc...@paragonie.com
wrote:
Hi Internals Team,
I'm sure everyone is really focused (and excited) for PHP 7.0.0 later this
year, and many of you might not want to discuss what 7.1.x looks like yet.
The current state of cryptography in PHP is, well, abysmal. Our two main
choices for handling symmetric cryptography are libmcrypt (collecting dust
since 2007) and openssl, which lacks a streaming API (e.g. mcrypt_generic)
and GCM support.
While mcrypt is slowly decomposing in the corner and code is being
desperately migrated towards openssl in case a critical vulnerability is
discovered in the abandonware choice, the libsodium extension has been
growing steadily. Thanks to Remi, it should soon be compatible with both
PHP 5.x and 7.x (decided at compile-time). The libsodium library itself has
landed in Debian 8 and Ubuntu 15.04 and adoption is expected to persist by
the next Ubuntu LTS is released.
I think now is a good time to talk about the possibility of making
libsodium a core PHP extension, depending on where things are when we near
the 7.1 feature freeze.
I've just opened an RFC for precisely this purpose:
https://wiki.php.net/rfc/libsodium
These are examples from github
$nonce = Sodium::randombytes_buf(Sodium::CRYPTO_SECRETBOX_NONCEBYTES);
$key = [a binary string that must be CRYPTO_SECRETBOX_KEYBYTES long];
$ciphertext = Sodium::crypto_secretbox('test', $nonce, $key);
$plaintext = Sodium::crypto_secretbox_open($ciphertext, $nonce, $key);
We have coding standard.
https://github.com/php/php-src/blob/master/CODING_STANDARDS
6. Method names follow the 'studlyCaps' (also referred to as 'bumpy case'
or 'camel caps') naming convention, with care taken to minimize the
letter count. The initial letter of the name is lowercase, and each
letter that starts a new 'word' is capitalized::
Good:
'connect()'
'getData()'
'buildSomeWidget()'
Bad:
'get_Data()'
'buildsomewidget'
'getI()'
To include as a core extension, you need standard method names.
Keeping old names as alias is fine for me, but main names should be
standard names.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] [RFC] JSON number to string
24 мая 2015 г., в 19:02, Jakub Zelenka bu...@php.net написал(а): Hi, I would like to introduce my and Pasindu's RFC that proposes adding of new JSON options for converting number values to string when decoding and/or encoding: https://wiki.php.net/rfc/json_numeric_as_string Personally I'm not a big fun of these options because of their drawbacks (see RFC section about that) and because I think that Json Scheme is a better way to go. However I'm not sure when and if I have time for Json Schema implementation, so this could be useful for some users the meantime. That is especially case of JSON_FLOAT_TO_STRING for decoding (encoding is a bit weird at it requires usage ini precision to do something useful). That (decoding) seems like a sort of a variant of JSON_BIGINT_TO_STRING for floats. That will be probably the only option that I will be vote for. I'm not sure how JSON Schema would help here. The issue is about converting from json's huge numbers to limited PHP's numbers. Schema just doesn't have notion of native types Anyway, as I told in a previous thread, while approach of this rfc solves immediate problem, it is not future-proof flexible and exposing low-level type based parsing is a better idea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libpcre 8.37 requires extra flags (at least on AIX)
Hi, It seems to be AIX only thing, as it builds fine for me for Linux/Darwin. Any hints ? Kaplan On Wed, May 20, 2015 at 9:28 PM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! While building the PHP 5.6.9 (which has libpcre 8.37) it seems we're missing -lpthreads build flag (for cli SAPI), as this library upgrade added this requirement. The files requiring is pcrelib/sljit/sljitUtils.c 5.5.25, which doesn't have this file, works fine without the flag. I think this requirement should be reflected in ext/pcre/config0.m4 (or is there something more relevant?) Hmm... I wonder why it needs pthreads or does it depend on some config. Is it on AIX only? Because for me it builds fine on both Linux and Darwin. I think if it's 8.37 missing sljitUtils.c is a bug. -- Stas Malyshev smalys...@gmail.com
Re: [PHP-DEV] [RFC] [PHP 7.1] libsodium
How should we reconcile your standard recommendations with NaCl proper and
how libsodium is used in other languages?
I'll try to loop Frank Denis in on this conversation again, but any
specific objections (esp. bikeshedding) would probably be best moved
towards new issues on the jedisct1/libsodium GitHub repository.
On May 25, 2015 2:10 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Scott,
On Thu, May 21, 2015 at 10:15 AM, Scott Arciszewski sc...@paragonie.com
wrote:
Hi Internals Team,
I'm sure everyone is really focused (and excited) for PHP 7.0.0 later this
year, and many of you might not want to discuss what 7.1.x looks like yet.
The current state of cryptography in PHP is, well, abysmal. Our two main
choices for handling symmetric cryptography are libmcrypt (collecting dust
since 2007) and openssl, which lacks a streaming API (e.g. mcrypt_generic)
and GCM support.
While mcrypt is slowly decomposing in the corner and code is being
desperately migrated towards openssl in case a critical vulnerability is
discovered in the abandonware choice, the libsodium extension has been
growing steadily. Thanks to Remi, it should soon be compatible with both
PHP 5.x and 7.x (decided at compile-time). The libsodium library itself
has
landed in Debian 8 and Ubuntu 15.04 and adoption is expected to persist by
the next Ubuntu LTS is released.
I think now is a good time to talk about the possibility of making
libsodium a core PHP extension, depending on where things are when we near
the 7.1 feature freeze.
I've just opened an RFC for precisely this purpose:
https://wiki.php.net/rfc/libsodium
These are examples from github
$nonce = Sodium::randombytes_buf(Sodium::CRYPTO_SECRETBOX_NONCEBYTES);
$key = [a binary string that must be CRYPTO_SECRETBOX_KEYBYTES long];
$ciphertext = Sodium::crypto_secretbox('test', $nonce, $key);
$plaintext = Sodium::crypto_secretbox_open($ciphertext, $nonce, $key);
We have coding standard.
https://github.com/php/php-src/blob/master/CODING_STANDARDS
6. Method names follow the 'studlyCaps' (also referred to as 'bumpy case'
or 'camel caps') naming convention, with care taken to minimize the
letter count. The initial letter of the name is lowercase, and each
letter that starts a new 'word' is capitalized::
Good:
'connect()'
'getData()'
'buildSomeWidget()'
Bad:
'get_Data()'
'buildsomewidget'
'getI()'
To include as a core extension, you need standard method names.
Keeping old names as alias is fine for me, but main names should be
standard names.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
[PHP-DEV] Fatal error: isset(CONST_ARRAY['key']) PHP 5.6
?php const CONST_ARRAY = [ 'key' = 'value' ]; isset(CONST_ARRAY['key']); // Fatal error: Cannot use isset() on the result of an expression (you can use null !== expression instead) ? It is design, or a bug? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RIP: NSAPI SAPI Plugin (unfortunately - thanks Oracle)
Hi, OK, this looks fine. Maybe we should involve Oracle people. Unfortunately, I have no direct contact regarding iPlanet. I have good contacts to the Oracle Quality Assurance team in Ireland, but that is regarding Java. But those people are not responsible to this issue. At the time I was investigating on the RFC, there already was a negative answer from the iPlanet team. So we already knew at that time they won't support it, it's stated in the RFC. Yes. But they never ever supported the plugin actively, so this was no real news at the time of the RFC. The SAPI was originally written by Jayakumar Muthukumarasamy, I took over in 2003. At that time there was no FastCGI support in the webserver, so the NSAPI plugin was the only working solution - and a great one (with just the well-known TLS problems, which was PHP's fault, not Sun/Oracle's). I improved it to be as most compliant to the Apache SAPI - it (still) works fine with most Content Management systems and MediaWiki (if you manage to make Rewrite rules of Apache working, that those CMS mostly need; this was fixed in iPlanet 7, where you can have rewrite rules - just with other syntax). In my personal opinion: If you have contact to iPlanet people at Oracle, maybe you should contact them again (or send me the contact details). If they would provide a working (developer) download location for the latest 7.0.21 version (released a month ago with TLS 1.2 support), we could start supporting it. But without any download location, it is impossible to support it. You should also remind them: Although they recommend to use FastCGI, it is impossible to support this webserver from our side without a developer download to test. So we can verify that FastCGI works. I would like to have support for handling error pages with FastCGI (so you can present 404 not found pages using PHP or directory listings). All this was possible with the NSAPI plugin, but to test this out with iPlanet and FastCGI we would need a download location. But if they show no interest, let NSAPI die :-( Uwe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fatal error: isset(CONST_ARRAY['key']) PHP 5.6
S.A.N wrote: ?php const CONST_ARRAY = [ 'key' = 'value' ]; isset(CONST_ARRAY['key']); // Fatal error: Cannot use isset() on the result of an expression (you can use null !== expression instead) ? It is design, or a bug? It is by design; the documentation states[1]: | isset() only works with variables as passing anything else will | result in a parse error. [1] http://php.net/manual/en/function.isset.php#refsect1-function.isset-notes -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fatal error: isset(CONST_ARRAY['key']) PHP 5.6
It is by design; the documentation states[1]: | isset() only works with variables as passing anything else will | result in a parse error. [1] http://php.net/manual/en/function.isset.php#refsect1-function.isset-notes Ok, the way it works in PHP 7. But the speed of access to const the array (ARR['key']) is 5 times slower, in comparison with the variable ($arr['key']) :( -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] JSON number to string
Hi,
On Mon, May 25, 2015 at 7:59 AM, Alexey Zakhlestin indey...@gmail.com
wrote:
I'm not sure how JSON Schema would help here. The issue is about
converting from json's huge numbers to limited PHP's numbers. Schema just
doesn't have notion of native types
The idea would be to use JSON schema to specify structure of the JSON and
select just the specific parts that can be converted to string. Let's
imagine that you have object with this structure:
{
a: 1.23234,
b: 1.1
}
Now you really don't want to loose precision for b but you would like to
use float for a. You can create a simple json schema:
{
title: Simple Object Schema,
type: object,
properties: {
a: {
type: number
},
b: {
type: string
}
}
}
The great thing on JSON Schema is that it is not limited on the specified
fields (the schema of json core schema does not disable
additionalProperties which means that any additional properties are
allowed). That means that we could add our parameter to specify a class of
the object. For example if we create classes that you proposed in the
previous thread, we could do following:
{
title: Simple Object Schema,
type: object,
properties: {
a: {
type: number
},
b: {
type: object,
class: Json\Float
}
}
}
It would probably require some allowing only classes that implements some
interface which allows JSON serialization (encoding) as well as
unserialization (decoding). That could be also used for user classes. We
would also need some flags to select type of the validation (strict
validation, validation with conversion if possible...).
There is much more that could be done including overloading validation
errors... JsonSchema adds of course more features that are however
off-topic...
Anyway, as I told in a previous thread, while approach of this rfc solves
immediate problem, it is not future-proof flexible and exposing low-level
type based parsing is a better idea
IIRC your initial proposal was about converting everything to objects which
is not flexible at all as it suffers exactly from the same problems as this
RFC. The only difference is using object instead of string. I think that
the above is much more flexible...
However as I said before it is quite a big feature that could be done only
in the minor version and requires considerably more time for implementation.
Cheers
Jakub
Re: [PHP-DEV] Fatal error: isset(CONST_ARRAY['key']) PHP 5.6
S.A.N in php.internals (Mon, 25 May 2015 16:09:42 +0300): It is by design; the documentation states[1]: | isset() only works with variables as passing anything else will | result in a parse error. [1] http://php.net/manual/en/function.isset.php#refsect1-function.isset-notes Ok, the way it works in PHP 7. There was some discussion on contant arrays on Stackoverflow with an answer by Andrea Faulds (with a link to changes between 5.6 and 7.0): http://stackoverflow.com/a/27413238/872051 Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ::class wrong case
On Mon, 25 May 2015 20:47:32 +0300, Marc Bennewitz dev@mabe.berlin wrote: Hi, I have noted that detecting a class name using ::class it will return the called case instead of the original case. see http://3v4l.org/97K36 That's annoying as I like to check the right class case on autoload to detect mistakes. Sure, class names in PHP are case-insensitive but filesystems aren't and most autoloader using the FS to find the right file. To catch such kind of mistakes I would like to implement a fast check in my autoloader to get noted on development instead on production. It's currently only possible with ReflectionClass but this will be much slower as with ::class. Are there any reasons to get the called case of the class instead or the original one? Marc This happens because ::class construction is evaluated at compiled time, without triggering autoloader. That means compiler doesn't know what will be the actual name of a class, it just gives you what you asked for. It's currently only possible with ReflectionClass but this will be much slower as with ::class. It's only possible with ReflectionClass if this class was already loaded. There's one way for your autoloader to know if the class name has characters in a wrong case - build a class map and do a check based on this map. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Throwable Interface
On 05/24/2015 10:11 PM, Aaron Piotrowski wrote: On May 24, 2015, at 2:08 PM, Marc Bennewitz dev@mabe.berlin wrote: Where are the new classes and the interface located if it's not in the global namespace or do I muss something? Sorry if what I wrote wasn’t clear. Throwable, Error, TypeError, and ParseError will be built-in interfaces/classes in the root namespaces. So users will not be able to make classes with those exact names, but classes with those names in a non-global namespace (e.g., \Vendor\Package\TypeError) will still be possible. I’ve updated the RFC to make this clearer. Thanks If I remember right the TypeException/TypeError will be thrown in some cases of internal functions with strict argument count. In my opinion a missing argument or to much arguments has nothing to do with the type and should have it's own Exception/Error class. I believe this actually generates a warning, it does not throw an exception. However, this does remind me of another point: It is possible that more classes extending Error could be created in the future for different error reasons. Anything that throws an Error could later be changed to throw an object extending Error without a BC break. This is a separate issue though and could be discussed in a future RFC. Ok than I remember wrong. Aaron Piotrowski Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Throwable Interface
On 05/24/2015 11:32 PM, Yasuo Ohgaki wrote: Hi Aaron, On Sun, May 24, 2015 at 5:12 AM, Aaron Piotrowski aa...@icicle.io wrote: I’ve created an RFC for modifying the exception hierarchy for PHP 7, adding Throwable interface and renaming the exceptions thrown from fatal errors. The RFC is now ready for discussion. RFC: https://wiki.php.net/rfc/throwable-interface https://wiki.php.net/rfc/throwable-interface Pull Request: https://github.com/php/php-src/pull/1284 https://github.com/php/php-src/pull/1284 Does this include internal function type errors? e.g. $ php -r 'var_dump(mt_srand(999));' PHP Warning: mt_srand() expects parameter 1 to be integer, string given in Command line code on line 1 NULL If not, please make these exceptions rather than E_WARNING. We need consistency here. This would be great for strict_types mode as there it results in a fatal error. http://3v4l.org/vHl8K Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fatal error: isset(CONST_ARRAY['key']) PHP 5.6
There was some discussion on contant arrays on Stackoverflow with an answer by Andrea Faulds (with a link to changes between 5.6 and 7.0): http://stackoverflow.com/a/27413238/872051 Ok, thank. Why the speed of access to const the array ARR['key'] is 500% slower, in comparison with the variable $arr['key']? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Throwable Interface
On 24/05/2015 22:32, Yasuo Ohgaki wrote: Does this include internal function type errors? e.g. $ php -r 'var_dump(mt_srand(999));' PHP Warning: mt_srand() expects parameter 1 to be integer, string given in Command line code on line 1 NULL If not, please make these exceptions rather than E_WARNING. We need consistency here. Changing a Warning to an Exception is a much bigger deal than changing an Error to an Exception. While an Exception *can* be caught, the fundamental nature of it is that it is *fatal* if it is not caught. So you would be changing an advisory warning to a fatal error. There might be cases where this would be sensible, but this has nothing to do with a) changing Errors to Exceptions (which has already passed) or b) changing the hierarchy to add a Throwable interface (the subject of this thread). Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Exception message cleanup
On Thu, Apr 9, 2015 at 10:04 AM, Nikita Popov nikita@gmail.com wrote:
Hi internals!
A lot of people have been confused about engine exceptions currently
displaying as normal fatal errors (if they aren't caught). We'll have to
change this to use exception messages.
Before doing this I'd like to clean up the messages a bit to make them
more friendly for CLI usage. Currently the messages are so cluttered that
it's hard to find the actual error message if you're in an 80 char window.
Patch is here: https://github.com/php/php-src/pull/1226
Previous message:
Fatal error: Uncaught exception 'UnexpectedValueException' with message
'Failed to open directory ' in %s:%d
Stack trace:
#0 %s(%d): DirectoryIterator-__construct('\x00/abc')
#1 {main}
thrown in %s on line %d
New message:
UnexpectedValueException: Failed to open directory in %s on line %d
Stack trace:
#0 %s(%d): DirectoryIterator-__construct('\x00/abc')
#1 {main}
Essentially exceptions would display like ordinary error, but with Fatal
error / Warning / ... replaced by the exception name, and showing a
stack trace after the error.
A side-effect of the change is that uncaught exceptions will always be
displayed canonically and not based on __toString output. To modify display
of exception output, people should modify the respective properties of the
exception.
An update on this:
EngineException and TypeException now display as normal exceptions
(including stack trace). ParseException still show as a Parse error. I
don't plan to change that one.
Instead of the relatively aggressive message changes described above I've
only landed a small tweak (see
https://github.com/php/php-src/commit/3ae995f03c8f60c4a4c9718262545cf5a6a08da3),
which fixes the problem with nested quotes but keeps current structure.
Nikita
Re: [PHP-DEV] ::class wrong case
On Mon, May 25, 2015 at 11:47 AM, Marc Bennewitz dev@mabe.berlin wrote:
Hi,
I have noted that detecting a class name using ::class it will return the
called case instead of the original case.
see http://3v4l.org/97K36
That's annoying as I like to check the right class case on autoload to
detect mistakes.
Sure, class names in PHP are case-insensitive but filesystems aren't and
most autoloader using the FS to find the right file. To catch such kind of
mistakes I would like to implement a fast check in my autoloader to get
noted on development instead on production. It's currently only possible
with ReflectionClass but this will be much slower as with ::class.
Are there any reasons to get the called case of the class instead or the
original one?
The way this is implemented means that the class doesn't even have to
exist. It's purely compile-time expansion. The identifier doesn't even
have to be a class at all[1]:
?php
namespace foo;
function bar(){}
var_dump(bar::class); // string(7) foo\bar
?
This was not explained in the RFC at all, and had I known this I would
have voted against it personally.
[1] It doesn't work when you import a function name with `use
function` because it's only intended to work with classes and
class-like entities.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] JSON number to string
On 25 May 2015, at 18:40, Jakub Zelenka bu...@php.net wrote: Anyway, as I told in a previous thread, while approach of this rfc solves immediate problem, it is not future-proof flexible and exposing low-level type based parsing is a better idea IIRC your initial proposal was about converting everything to objects which is not flexible at all as it suffers exactly from the same problems as this RFC. The only difference is using object instead of string. I think that the above is much more flexible... However as I said before it is quite a big feature that could be done only in the minor version and requires considerably more time for implementation. The difference is, that object would preserve type information from the document. Source representation would always be the string, but you will be able to know if it was typed as a Number or as a literal String. After that, application’s logic can decide what it should do with it. But yeah, sure, that is a bigger feature А. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ::class wrong case
Hi, I have noted that detecting a class name using ::class it will return the called case instead of the original case. see http://3v4l.org/97K36 That's annoying as I like to check the right class case on autoload to detect mistakes. Sure, class names in PHP are case-insensitive but filesystems aren't and most autoloader using the FS to find the right file. To catch such kind of mistakes I would like to implement a fast check in my autoloader to get noted on development instead on production. It's currently only possible with ReflectionClass but this will be much slower as with ::class. Are there any reasons to get the called case of the class instead or the original one? Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
