Re: [PHP-DEV] PHP 7.1.4 is available
Morning David, I've updated the changelog, not sure why the generation didn't work, but will be sure to verify in future. I've added the news entry in 7.1 branch that was missing for opcache also. Thanks for the heads up :) Cheers Joe On Thu, Apr 13, 2017 at 8:20 PM, David Zuelke wrote: > The changelog is incomplete; stops at iconv. https://github.com/php/php- > src/commit/330a7b62c3558aa987ee80e12f1914347d3a9eee is also missing from > NEWS for 7.1.3 > > > > On 13. Apr 2017, at 18:43, Joe Watkins wrote: > > > > Evening, > > > > The PHP development team announces the immediate availability of PHP > 7.1.4. > > This is a bug fix release, all PHP 7.1 users are encouraged to upgrade. > > > > For source downloads of PHP 7.1.4, please visit the downloads page: > > > > https://www.php.net/downloads.php > > > > Windows binaries can be found at http://windows.php.net/download > > > > The list of changes is recorded in the change log: > > http://www.php.net/ChangeLog-7.php#7.1.4 > > > > Follows is verification information. > > > > Cheers > > Joe > > > > php-7.1.4.tar.bz2 > > SHA256 hash: > > 39bf697836e2760b3a44ea322e9e5f1f5b1f07abeb0111f6495eff7538e25805 > > PGP signature: > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1 > > > > iQEcBAABCAAGBQJY76qaAAoJEPm6Ctoxy9iecEcH/27ET+GcOEIf9oRKl4ndNjjm > > XTSguNKokk5bwTVBUaFvbujHdbdaDHWGESOu0ZP8T6SaK8h9eK4TRoEajckxjx0o > > BXQXs+3DLpujotpSkx4FGh0CC/1tl8x7CkIq5k8l7Nn14JPA+Ro9wItGbCO7d1dN > > KRN52rqNzgLcFoRoCqK+SLJc6V3Fb9ewdRUU8xo78+60T0cZPqpTeSNXW/Y3Swph > > Ua7uuwSft07Qwiz+T0km1XS8/1s57YatR/nV79rVw0ijNyENc/jz9sV7BxAYcgwt > > UUuZx1BtfhHjrdwM9wsgpm/wG2VrxBQIUe8LXMIkjJwX/VgkPhpkvluzdguOY7A= > > =iggm > > -END PGP SIGNATURE- > > > > > > php-7.1.4.tar.gz > > SHA256 hash: > > ed0006c86de503684dde04c6dd811ea2354a3b6d10ebd9f0cb103dcd28f0e70f > > PGP signature: > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1 > > > > iQEcBAABCAAGBQJY76qiAAoJEPm6Ctoxy9ieJUgIAK70tYU9dUa+iMUYUksO8Qf2 > > 9yi2lX/8QSaaFXYeiUirPKShSQf05vs8FeAzlPBbBGhAoQ5mWA8ivKhlP2/olMJR > > MFakWWJ4Ae/k2Cl2ChlvpqRbhC11xRW2VHbHCMReWuOM1bOdxv1DWUBmFFt/F/b7 > > lIn1auVKS+euHtVK5LHpD43pCYW0ouDxG/N1BVrhU2IlSNY7CR7ThjSCrzUDtdu0 > > 9Ld1W81+7UJn47KWScq25gAXoUizF1DeJI3S7X40hNOStDWxUA/VcsbBybtsh1jw > > U07CrWB/DeK1/LMe6iLpDoFPSHQHmpxVjFkb+2fryRBJWjkZ+s1YPH+xum9E8/g= > > =CWU9 > > -END PGP SIGNATURE- > > > > > > php-7.1.4.tar.xz > > SHA256 hash: > > 71514386adf3e963df087c2044a0b3747900b8b1fc8da3a99f0a0ae9180d300b > > PGP signature: > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1 > > > > iQEcBAABCAAGBQJY76qlAAoJEPm6Ctoxy9ieiacH/iREeJqVqGU6eevvXBFrJmEj > > nK2XTg59PHKYAXxg5h6Sq3xREvW2JLZYW9Bx49I6Zk+dxMY7kqSHKEftqthG2GtD > > clGx5NOhlQySnFcyHVMSuElL/sWaKWURERENAXHZerv0n1k9FJP0wuJy6DBNxHFM > > 6eRFJ/7lY9HcVG/OKps5DOJkI6+RHUwZ5Yad37I1nQcsgfutWaASLHYKNRw3nTRn > > Xg0PTGarviNJCkm2CyGwXRYQpBzpd+YQuHN9/tjKyY471VYkGSTw3kUWgA9tyzeP > > Wy99JVKS5/8wWLGtC6VuvQoPy+Qd186rpCRgB9RDF4RD6sg/CyX6nxErMqIP/EE= > > =D+kM > > -END PGP SIGNATURE- > >
Re: [PHP-DEV] rfc concepts
There have already been several such proposals made in past years, and discussed at length here on the mailing list. See C# Style Accessors past RFC: https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 and alternatives: https://wiki.php.net/rfc/propertygetsetsyntax-alternative-typehinting-syntax Since PHP 7 already supports scalar type hints and strict mode, as well as magic getters/setters, pretty much all of your aforementioned concepts are already possible in PHP with a bit of boiler plate. The declarative accessors obviously have some benefits like less verbosity and more concise syntax, but we've been down this road before in the past and I'd suggest reading the discussions around those RFCs, with similar ideas, which were declined or withdrawn and coming up with a more constructive approach if you want it to gain any critical mass. It's going to be a tough sell if you just come back with the same approach. On Thu, Apr 13, 2017 at 9:40 PM, Kelt Dockins wrote: > Hi everybody, > > > I've been using php for many years now and it really is a great language. > My friend and I were talking about additional things we would want in php - > sort of like a wishlist. I came up with 3 things that I think would make > php even more awesome and I wanted to share these concepts with this list > and I'd love to get feedback. I haven't done any c programming in years but > I'd be open to working on these concepts if enough people wanted them. > > > > 1. use strict mode > > > ``` > > class Bar { } > > > class Foo > > { >use strict; > > } > > > $bar = new Bar; > > $bar->thing = 1; // no problem > > > $foo = new Foo; > > $foo->thing = 1; // throws error because thing attribute does not > exists > > ``` > > > > 2. type hinting class properties > > > ``` > > class Foo > > { >public $thing : int; > > } > > > $foo = new Foo; > > $foo->thing = 1; // works fine > > $foo->thing = 'string'; // throws Typehint > > ``` > > > 3. auto properties > > > ``` > > class Foo > > { > >private $thing1 { > > get, set > >}; > > >private $thing2 { > > get > >}; > > >private $thing3 { > > set > >}; > > } > > > $foo = new Foo; > > $foo->thing1 = 'asdf'; > > echo $foo->thing1; // echos 'asdf' > > > $foo->thing2 = 'asdf'; // throws error because no setter > > > $foo->thing3 = ''asdf'; // sets thing3 > > echo $foo->thing3; // throws error because no getter > > ``` > > > I'd love to hear what you all have to say about these things. Thanks in > advance for your feedback and time! > > > - Kelt >
[PHP-DEV] rfc concepts
Hi everybody, I've been using php for many years now and it really is a great language. My friend and I were talking about additional things we would want in php - sort of like a wishlist. I came up with 3 things that I think would make php even more awesome and I wanted to share these concepts with this list and I'd love to get feedback. I haven't done any c programming in years but I'd be open to working on these concepts if enough people wanted them. 1. use strict mode ``` class Bar { } class Foo { use strict; } $bar = new Bar; $bar->thing = 1; // no problem $foo = new Foo; $foo->thing = 1; // throws error because thing attribute does not exists ``` 2. type hinting class properties ``` class Foo { public $thing : int; } $foo = new Foo; $foo->thing = 1; // works fine $foo->thing = 'string'; // throws Typehint ``` 3. auto properties ``` class Foo { private $thing1 { get, set }; private $thing2 { get }; private $thing3 { set }; } $foo = new Foo; $foo->thing1 = 'asdf'; echo $foo->thing1; // echos 'asdf' $foo->thing2 = 'asdf'; // throws error because no setter $foo->thing3 = ''asdf'; // sets thing3 echo $foo->thing3; // throws error because no getter ``` I'd love to hear what you all have to say about these things. Thanks in advance for your feedback and time! - Kelt
[PHP-DEV] NEUTRAL Benchmark Results for PHP Master 2017-04-13
Results for project PHP master, build date 2017-04-13 08:28:43-07:00 commit: 04fe5e9 previous commit:fd0e71d revision date: 2017-04-12 12:56:13+02:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB mem:128 GB os: CentOS 7.1 kernel: Linux 3.10.0-229.4.2.el7.x86_64 Baseline results were generated using release php-7.0.0, with hash 60fffd2 from 2015-12-01 04:16:47+00:00 --- benchmark relative change since change since current rev run std_dev* last run baseline with PGO --- :-| Wordpress 4.2.2 cgi -T1 0.13% 0.04% 0.74% 6.68% :-| Drupal 7.36 cgi -T1 0.18% -0.11% 0.63% 3.75% :-| MediaWiki 1.23.9 cgi -T5000 0.28% -0.09% 1.42% 3.51% :-| bench.php cgi -T100 0.07% 0.08% 37.94% -1.15% :-| micro_bench.php cgi -T10 0.01% -0.01% 15.18% 0.73% :-| mandelbrot.php cgi -T100 0.00% 0.00% 34.99% 2.21% --- * Relative Standard Deviation (Standard Deviation/Average) If this is not displayed properly please visit our results page here: http://languagesperformance.intel.com/neutral-benchmark-results-for-php-master-2017-04-13/ Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in fetches/second while all others are measured in seconds. More details on measurements methodology at: https://01.org/lp/documentation/php-environment-setup. Subject Label Legend: Attributes are determined based on the performance evolution of the workloads compared to the previous measurement iteration. NEUTRAL: performance did not change by more than 1% for any workload GOOD: performance improved by more than 1% for at least one workload and there is no regression greater than 1% BAD: performance dropped by more than 1% for at least one workload and there is no improvement greater than 1% UGLY: performance improved by more than 1% for at least one workload and also dropped by more than 1% for at least one workload Our lab does a nightly source pull and build of the PHP project and measures performance changes against the previous stable version and the previous nightly measurement. This is provided as a service to the community so that quality issues with current hardware can be identified quickly. Intel technologies' features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Improve hash_hkdf() parameter
Hi all, On Fri, Apr 14, 2017 at 6:22 AM, Yasuo Ohgaki wrote: > > On Thu, Apr 13, 2017 at 5:11 PM, Pieter Hordijk > wrote: > >> Is this really something we need in our official docs instead of for >> example >> on a personal blog? >> > > I wrote draft doc patch. > Please verify. > I used "very low entropy salt" for this CSRF token because "Input key is strong, very low entropy salt is acceptable". To avoid confusions, I revised the doc patch. Index: en/reference/hash/functions/hash-hkdf.xml === --- en/reference/hash/functions/hash-hkdf.xml(リビジョン 342317) +++ en/reference/hash/functions/hash-hkdf.xml(作業コピー) @@ -3,7 +3,7 @@ http://docbook.org/ns/docbook"; xmlns:xlink="http://www.w3.org/1999/xlink";> hash_hkdf - Generate a HKDF key derivation of a supplied key input + Derive secure new key from existing key by using HKDF &reftitle.description; @@ -16,6 +16,20 @@ stringsalt'' + + RFC 5869 defines HKDF (HMAC based Key Derivation Function) which + is general purpose KDF. HKDF could be useful for many PHP + applications that require temporary keys, such CSRF token, + pre-signed key for URI, password for password protected + URI, and so on. + + + + When info and length + is not required for your program, more efficient + hash_hmac could be used instead. + + &reftitle.parameters; @@ -25,7 +39,7 @@ algo - Name of selected hashing algorithm (i.e. "sha256", "sha512", "haval160,4", etc..) + Name of selected hashing algorithm (i.e. "sha3-256", "sha3-512", "sha256", "sha512", "haval160,4", etc..) See hash_algos for a list of supported algorithms. @@ -39,7 +53,7 @@ ikm - Input keying material (raw binary). Cannot be empty. + Input keying material. Cannot be empty. @@ -60,7 +74,8 @@ info - Application/context-specific info string. + Application/context-specific info string. Info is intended for + public information such as user ID, protocol version, etc. @@ -71,8 +86,34 @@ Salt to use during derivation. - While optional, adding random salt significantly improves the strength of HKDF. +While optional, adding random salt significantly improves the +strength of HKDF. Salt could be either secret or +non-secret. It is used as "Pre Shared Key" in many use cases. +Strong value is preferred. e.g. Use random_bytes. +Optimal salt size is size of used hash algorithm. + + + Although salt is the last optional parameter, salt is the + most important parameter for key security. Omitted salt is + indication of inappropriate design in most cases. Users must + set appropriate salt value whenever it is possible. Omit salt + only when it cannot be used. + + + Strong salt is mandatory and must be kept secret when input + key is weak, otherwise input key security will not be kept. + When input key is strong, low entropy salt is acceptable. + However, providing strong salt is the best practice for the + best possible key security. Strong salt is strongly recommended + long life input keys. + + + Salt must not be able to be controlled by users. i.e. User + must not be able to set salt value and get derived key. User + controlled salt allows input key analysis to attackers. + + @@ -101,6 +142,99 @@ &reftitle.examples; +URI specific CSRF token that supports expiration by hash_hkdf + + + + + Common CSRF token uses the same token value for a session and all + URI. This example CSRF token expires and is specific to a + URI. i.e. CSRF token http://example.com/form_A/ is not valid for + http://example.com/form_B/ Since token value is computed, no + database is required. + + + + + hash_hkdf example + + + @@ -130,6 +288,7 @@ &reftitle.seealso; +hash_hmac hash_pbkdf2 RFC 5869 userland implementation -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC][VOTE] Improve hash_hkdf() parameter
Hi Pieter and all, On Thu, Apr 13, 2017 at 5:11 PM, Pieter Hordijk wrote: > Is this really something we need in our official docs instead of for > example > on a personal blog? > I wrote draft doc patch. Please verify. Index: en/reference/hash/functions/hash-hkdf.xml === --- en/reference/hash/functions/hash-hkdf.xml(リビジョン 342317) +++ en/reference/hash/functions/hash-hkdf.xml(作業コピー) @@ -3,7 +3,7 @@ http://docbook.org/ns/docbook"; xmlns:xlink="http://www.w3.org/1999/xlink";> hash_hkdf - Generate a HKDF key derivation of a supplied key input + Derive secure new key from existing key by using HKDF &reftitle.description; @@ -16,6 +16,20 @@ stringsalt'' + + RFC 5869 defines HKDF (HMAC based Key Derivation Function) which + is general purpose KDF. HKDF could be useful for many PHP + applications that require temporary keys, such CSRF token, + pre-signed key for URI, password for password protected + URI, and so on. + + + + When info and length + is not required for your program, more efficient + hash_hmac could be used instead. + + &reftitle.parameters; @@ -25,7 +39,7 @@ algo - Name of selected hashing algorithm (i.e. "sha256", "sha512", "haval160,4", etc..) + Name of selected hashing algorithm (i.e. "sha3-256", "sha3-512", "sha256", "sha512", "haval160,4", etc..) See hash_algos for a list of supported algorithms. @@ -39,7 +53,7 @@ ikm - Input keying material (raw binary). Cannot be empty. + Input keying material. Cannot be empty. @@ -60,7 +74,8 @@ info - Application/context-specific info string. + Application/context-specific info string. Info is intended for + public information such as user ID, protocol version, etc. @@ -71,8 +86,32 @@ Salt to use during derivation. - While optional, adding random salt significantly improves the strength of HKDF. +While optional, adding random salt significantly improves the +strength of HKDF. Salt could be either secret or +non-secret. It is used as "Pre Shared Key" in many use cases. +Strong value is preferred. e.g. Use random_bytes. +Optimal salt size is size of used hash algorithm. + + + Although salt is the last optional parameter, salt is the + most important parameter for key security. Omitted salt is + indication of inappropriate design in most cases. Users must + set appropriate salt value whenever it is possible. Omit salt + only when it cannot be used. + + + Strong salt is mandatory and must be kept secret when input + key is weak, otherwise input key security will not be kept. + Even when input key is strong, providing strong salt is the + best practice for the best possible key security. + + + Salt must not be able to be controlled by users. i.e. User + must not be able to set salt value and get derived key. User + controlled salt allows input key analysis to attackers. + + @@ -101,6 +140,99 @@ &reftitle.examples; +URI specific CSRF token that supports expiration by hash_hkdf + + + + + Common CSRF token uses the same token value for a session and all + URI. This example CSRF token expires and is specific to a + URI. i.e. CSRF token http://example.com/form_A/ is not valid for + http://example.com/form_B/ Since token value is computed, no + database is required. + + + + + hash_hkdf example + + + @@ -130,6 +286,7 @@ &reftitle.seealso; +hash_hmac hash_pbkdf2 RFC 5869 userland implementation -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] PHP 7.1.4 is available
The changelog is incomplete; stops at iconv. https://github.com/php/php-src/commit/330a7b62c3558aa987ee80e12f1914347d3a9eee is also missing from NEWS for 7.1.3 > On 13. Apr 2017, at 18:43, Joe Watkins wrote: > > Evening, > > The PHP development team announces the immediate availability of PHP 7.1.4. > This is a bug fix release, all PHP 7.1 users are encouraged to upgrade. > > For source downloads of PHP 7.1.4, please visit the downloads page: > > https://www.php.net/downloads.php > > Windows binaries can be found at http://windows.php.net/download > > The list of changes is recorded in the change log: > http://www.php.net/ChangeLog-7.php#7.1.4 > > Follows is verification information. > > Cheers > Joe > > php-7.1.4.tar.bz2 > SHA256 hash: > 39bf697836e2760b3a44ea322e9e5f1f5b1f07abeb0111f6495eff7538e25805 > PGP signature: > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > > iQEcBAABCAAGBQJY76qaAAoJEPm6Ctoxy9iecEcH/27ET+GcOEIf9oRKl4ndNjjm > XTSguNKokk5bwTVBUaFvbujHdbdaDHWGESOu0ZP8T6SaK8h9eK4TRoEajckxjx0o > BXQXs+3DLpujotpSkx4FGh0CC/1tl8x7CkIq5k8l7Nn14JPA+Ro9wItGbCO7d1dN > KRN52rqNzgLcFoRoCqK+SLJc6V3Fb9ewdRUU8xo78+60T0cZPqpTeSNXW/Y3Swph > Ua7uuwSft07Qwiz+T0km1XS8/1s57YatR/nV79rVw0ijNyENc/jz9sV7BxAYcgwt > UUuZx1BtfhHjrdwM9wsgpm/wG2VrxBQIUe8LXMIkjJwX/VgkPhpkvluzdguOY7A= > =iggm > -END PGP SIGNATURE- > > > php-7.1.4.tar.gz > SHA256 hash: > ed0006c86de503684dde04c6dd811ea2354a3b6d10ebd9f0cb103dcd28f0e70f > PGP signature: > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > > iQEcBAABCAAGBQJY76qiAAoJEPm6Ctoxy9ieJUgIAK70tYU9dUa+iMUYUksO8Qf2 > 9yi2lX/8QSaaFXYeiUirPKShSQf05vs8FeAzlPBbBGhAoQ5mWA8ivKhlP2/olMJR > MFakWWJ4Ae/k2Cl2ChlvpqRbhC11xRW2VHbHCMReWuOM1bOdxv1DWUBmFFt/F/b7 > lIn1auVKS+euHtVK5LHpD43pCYW0ouDxG/N1BVrhU2IlSNY7CR7ThjSCrzUDtdu0 > 9Ld1W81+7UJn47KWScq25gAXoUizF1DeJI3S7X40hNOStDWxUA/VcsbBybtsh1jw > U07CrWB/DeK1/LMe6iLpDoFPSHQHmpxVjFkb+2fryRBJWjkZ+s1YPH+xum9E8/g= > =CWU9 > -END PGP SIGNATURE- > > > php-7.1.4.tar.xz > SHA256 hash: > 71514386adf3e963df087c2044a0b3747900b8b1fc8da3a99f0a0ae9180d300b > PGP signature: > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > > iQEcBAABCAAGBQJY76qlAAoJEPm6Ctoxy9ieiacH/iREeJqVqGU6eevvXBFrJmEj > nK2XTg59PHKYAXxg5h6Sq3xREvW2JLZYW9Bx49I6Zk+dxMY7kqSHKEftqthG2GtD > clGx5NOhlQySnFcyHVMSuElL/sWaKWURERENAXHZerv0n1k9FJP0wuJy6DBNxHFM > 6eRFJ/7lY9HcVG/OKps5DOJkI6+RHUwZ5Yad37I1nQcsgfutWaASLHYKNRw3nTRn > Xg0PTGarviNJCkm2CyGwXRYQpBzpd+YQuHN9/tjKyY471VYkGSTw3kUWgA9tyzeP > Wy99JVKS5/8wWLGtC6VuvQoPy+Qd186rpCRgB9RDF4RD6sg/CyX6nxErMqIP/EE= > =D+kM > -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 7.1.4 is available
Evening, The PHP development team announces the immediate availability of PHP 7.1.4. This is a bug fix release, all PHP 7.1 users are encouraged to upgrade. For source downloads of PHP 7.1.4, please visit the downloads page: https://www.php.net/downloads.php Windows binaries can be found at http://windows.php.net/download The list of changes is recorded in the change log: http://www.php.net/ChangeLog-7.php#7.1.4 Follows is verification information. Cheers Joe php-7.1.4.tar.bz2 SHA256 hash: 39bf697836e2760b3a44ea322e9e5f1f5b1f07abeb0111f6495eff7538e25805 PGP signature: -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAABCAAGBQJY76qaAAoJEPm6Ctoxy9iecEcH/27ET+GcOEIf9oRKl4ndNjjm XTSguNKokk5bwTVBUaFvbujHdbdaDHWGESOu0ZP8T6SaK8h9eK4TRoEajckxjx0o BXQXs+3DLpujotpSkx4FGh0CC/1tl8x7CkIq5k8l7Nn14JPA+Ro9wItGbCO7d1dN KRN52rqNzgLcFoRoCqK+SLJc6V3Fb9ewdRUU8xo78+60T0cZPqpTeSNXW/Y3Swph Ua7uuwSft07Qwiz+T0km1XS8/1s57YatR/nV79rVw0ijNyENc/jz9sV7BxAYcgwt UUuZx1BtfhHjrdwM9wsgpm/wG2VrxBQIUe8LXMIkjJwX/VgkPhpkvluzdguOY7A= =iggm -END PGP SIGNATURE- php-7.1.4.tar.gz SHA256 hash: ed0006c86de503684dde04c6dd811ea2354a3b6d10ebd9f0cb103dcd28f0e70f PGP signature: -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAABCAAGBQJY76qiAAoJEPm6Ctoxy9ieJUgIAK70tYU9dUa+iMUYUksO8Qf2 9yi2lX/8QSaaFXYeiUirPKShSQf05vs8FeAzlPBbBGhAoQ5mWA8ivKhlP2/olMJR MFakWWJ4Ae/k2Cl2ChlvpqRbhC11xRW2VHbHCMReWuOM1bOdxv1DWUBmFFt/F/b7 lIn1auVKS+euHtVK5LHpD43pCYW0ouDxG/N1BVrhU2IlSNY7CR7ThjSCrzUDtdu0 9Ld1W81+7UJn47KWScq25gAXoUizF1DeJI3S7X40hNOStDWxUA/VcsbBybtsh1jw U07CrWB/DeK1/LMe6iLpDoFPSHQHmpxVjFkb+2fryRBJWjkZ+s1YPH+xum9E8/g= =CWU9 -END PGP SIGNATURE- php-7.1.4.tar.xz SHA256 hash: 71514386adf3e963df087c2044a0b3747900b8b1fc8da3a99f0a0ae9180d300b PGP signature: -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAABCAAGBQJY76qlAAoJEPm6Ctoxy9ieiacH/iREeJqVqGU6eevvXBFrJmEj nK2XTg59PHKYAXxg5h6Sq3xREvW2JLZYW9Bx49I6Zk+dxMY7kqSHKEftqthG2GtD clGx5NOhlQySnFcyHVMSuElL/sWaKWURERENAXHZerv0n1k9FJP0wuJy6DBNxHFM 6eRFJ/7lY9HcVG/OKps5DOJkI6+RHUwZ5Yad37I1nQcsgfutWaASLHYKNRw3nTRn Xg0PTGarviNJCkm2CyGwXRYQpBzpd+YQuHN9/tjKyY471VYkGSTw3kUWgA9tyzeP Wy99JVKS5/8wWLGtC6VuvQoPy+Qd186rpCRgB9RDF4RD6sg/CyX6nxErMqIP/EE= =D+kM -END PGP SIGNATURE-
[PHP-DEV] Re: Improve hash_hkdf() parameter
wout van gils in php.internals (Thu, 13 Apr 2017 15:13:40 +): >Kan iemand mij eindelijk eens uitschrijven.? Dat moet je zelf doen: http://php.net/mailing-lists.php Onderaan. -- Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Improve hash_hkdf() parameter
Kan iemand mij eindelijk eens uitschrijven.? ?? Van: Pieter Hordijk Verzonden: donderdag 13 april 2017 08:11 Aan: Yasuo Ohgaki CC: Joe Watkins; Andrey Andreev; internals@lists.php.net; php...@lists.php.net Onderwerp: [PHP-DOC] Re: [PHP-DEV] [RFC][VOTE] Improve hash_hkdf() parameter - Original Message - > From: "Yasuo Ohgaki" > To: "Joe Watkins" , "Andrey Andreev" > Cc: internals@lists.php.net > Sent: Thursday, April 13, 2017 1:07:19 AM > Subject: Re: [PHP-DEV] [RFC][VOTE] Improve hash_hkdf() parameter > Hi Joe, > > On Wed, Apr 12, 2017 at 7:46 PM, Joe Watkins wrote: > >> This RFC was left open for 5 days past the end of voting as declared on >> the RFC. >> > > Thank you, I forgot about this. > IMHO, it's a shame for us we should have inconsistent and insecure function > signature for a new function. > > I'm going to update the manual to add warning notes and example usages > like advanced CRFS token dedicated for specific URL with expiration time. > > I can think of length option only usage, but I cannot think usage that could > be useful for majority of PHP users like advanced CSRF token. Is this really something we need in our official docs instead of for example on a personal blog? To be honest I am afraid of ending up with something like the current state of the session docs. Which are imo way too broad / opinionated, non English, contains utterly confusing examples and / or flat out wrong and broken examples. Above already resulted in a stream of docs bugs regarding session pages and a lot of confused readers. By all means describe how functions work, but don't confuse readers with things most people won't ever need or are better suited as a (series of) blog posts / Stack Overflow post(s). My €0.02 cc-ing docs discussion to get them also involved in case somebody of the docs team has an opinion. > Andrey, > > Could you give us some length only and length/info only example > that could be useful for most PHP users. > It should be safe and recommended usage. > I suppose you should have some good examples. > > Thank you. > > -- > Yasuo Ohgaki > yohg...@ohgaki.net
[PHP-DEV] Re: Improve hash_hkdf() parameter
Kan iemand mij eindelijk eens uitschrijven.?
[PHP-DEV] PHP 7.0.18 is available
Hi, The PHP development team announces the immediate availability of PHP 7.0.18. Several bugs have been fixed. All PHP 7.0 users are encouraged to upgrade to this version. For source downloads of PHP 7.0.18 please visit our downloads page: http://www.php.net/downloads.php Windows binaries can be found on http://windows.php.net/download/ The list of changes is recorded in the ChangeLog: http://www.php.net/ChangeLog-7.php#7.0.18 Regards, Anatol Belski and Ferenc Kovacs php-7.0.18.tar.bz2 SHA256 hash: b20cc63d507032b39d8bb14cb64784e460b0e47997e90a8704b703bcbb233fd1 PGP signature: -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAABAgAGBQJY7K/dAAoJELyqMOqcDVdjQIQH+wYu+FvRtHk+WEjqH9Wx2tzW QSYm9TzKEiTL7/3vmqlHwo9n4CUt0OoAn/JijUHCxmEEoJg+IgcA8GakcaET1GBt M0iWEZrL4FlEX4QiLB+osPEW2lMxuZ3CCel/xZVgs1GE6w9uXw3XZoag40KppS4E ofGDDOz054gzWCxDQpkXHdPoHrmu6gIaJckqGm4zFrH9Ouz0Ue2zbaCArk8pLEWv GWutG2xNsCUyqQ5/F686xZqMwZPVHFjGqCc6ARrqXTMURz/EAm6LBsuQ8KwWvFsH Is3EhrnneQ4Jv5YXr+elsTHnB8VMD9xvR/oV+OFL4cDnXl8b6vASUjfm71J+/8s= =lunh -END PGP SIGNATURE- php-7.0.18.tar.gz SHA256 hash: e0fb336749d72e6c9cfcebb9b48497f004fa99f93b68c21cb3eb657053665e1d PGP signature: -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAABAgAGBQJY7K/hAAoJELyqMOqcDVdjMCsIAMPoA9tEe7wtRTLw1Eq0epcf lIMB1MJ7IJI5RPxvyCl9cT3oLBc3DLDazx6qusurmskrkuP1ALx2mAvi/EYoQYz/ PzKBHpTFIuKjtw/qIw9YrpQ7P6SLsUOJQ3Db/o/1QehJz0rrSbdg6MDxUtrIm9oX 6IhWzFPAbcL/x0fhVRgACpYmAYwyKqHitqOJdgi7hYiIr1938VYWz+ZHXBhKcJin anSljtH0mj5oGlsX8ALenh03cDpmuMiZ/RZhAPrQgN1DOA+u4UtOgHyMt+jmvExs Jjb7WU5qlGfO18Zou/Hoz0jYO9SDXjaz10cwI+zKI1/EM7hX683wWoyNbklITYA= =cFzc -END PGP SIGNATURE- php-7.0.18.tar.xz SHA256 hash: 679cffcdf2495dee5ab89bda595e678a1096136678b3a1d08f1f57ba347c234d PGP signature: -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAABAgAGBQJY7K/kAAoJELyqMOqcDVdjRPEIAKrWZLJ6BP1+q2cfbeQCBAbH LDyv7RMBBanDllfIYPXqI9YpP9kZHzGih5q+A9wSiKyB9thKiw6BmUnequjD7VCN fSkifkCsGuZWStDh08y1DrRlBcClCXTAlk3paWs4It85qpAs9Lycb6J7mFavHBli /mWlOrz+m04xrh0osvViQhlCnwHiwmeT4i3QGkDQw6ULzdMIs0dbRTFB8LOxsnI/ Id4ReuK57y6cWkX3wIanewRZ1Zjgz6GokXrs+7wVGc6/7GmnqJQ8l75KLIOVhekN Swi5TxUGqPpHWpsqbdHyf8JspOFJwQX+MptBjwvFpzxkhV/rNh8T6CdGWxhqbd8= =UzwG -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Prevent number_format() from returning negative zero
Just a reminder that I'll be putting the following RFC to vote in a few days. https://wiki.php.net/rfc/number_format_negative_zero I presume the silence is due to there being no more objections, so I look forward to the vote. Thanks, Craig
Re: [PHP-DEV] [RFC][VOTE] Improve hash_hkdf() parameter
Hi Pieter, On Thu, Apr 13, 2017 at 5:38 PM, Yasuo Ohgaki wrote: > > On Thu, Apr 13, 2017 at 5:11 PM, Pieter Hordijk > wrote: > >> To be honest I am afraid of ending up with something like the current >> state >> of the session docs. Which are imo way too broad / opinionated, non >> English, >> contains utterly confusing examples and / or flat out wrong and broken >> examples. >> Above already resulted in a stream of docs bugs regarding session pages >> and a lot of confused readers. >> > > You may consider my opinion as my personal opinion. I don't know of other > than > me who had that opinion then. > > After our session discussion, it seems OWASP adopted most of discussed > elements in their doc ;) > I'm not exactly sure which part you consider as personal blog. Current session management is too loose and insecure in many ways. Since mandatory features for precise session management are not implemented, the doc is intermediate. I'm willing to improve the doc and appreciate improvement suggestions always. Feel free to send to my personal mail address. Required information for precise and secure session management should be in Precise Session Management RFC https://wiki.php.net/rfc/precise_session_management I appreciate if one could add missing documentation for precise session management. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC][VOTE] Improve hash_hkdf() parameter
Hi Peiter, On Thu, Apr 13, 2017 at 5:11 PM, Pieter Hordijk wrote: > To be honest I am afraid of ending up with something like the current state > of the session docs. Which are imo way too broad / opinionated, non > English, > contains utterly confusing examples and / or flat out wrong and broken > examples. > Above already resulted in a stream of docs bugs regarding session pages > and a lot of confused readers. > You may consider my opinion as my personal opinion. I don't know of other than me who had that opinion then. After our session discussion, it seems OWASP adopted most of discussed elements in their doc ;) https://www.owasp.org/index.php/Session_Management_Cheat_Sheet Regards, P.S. My opinion is based on RFC 5869. In addition, it's totally nonsense to me to have completely different signature for hash_hkdf(). See the difference hash_hmac() and hash_pbkdf2(). hash_pbkdf2() is older KDF function. I should have mention in the RFC :( -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC][VOTE] Improve hash_hkdf() parameter
- Original Message - > From: "Yasuo Ohgaki" > To: "Joe Watkins" , "Andrey Andreev" > Cc: internals@lists.php.net > Sent: Thursday, April 13, 2017 1:07:19 AM > Subject: Re: [PHP-DEV] [RFC][VOTE] Improve hash_hkdf() parameter > Hi Joe, > > On Wed, Apr 12, 2017 at 7:46 PM, Joe Watkins wrote: > >> This RFC was left open for 5 days past the end of voting as declared on >> the RFC. >> > > Thank you, I forgot about this. > IMHO, it's a shame for us we should have inconsistent and insecure function > signature for a new function. > > I'm going to update the manual to add warning notes and example usages > like advanced CRFS token dedicated for specific URL with expiration time. > > I can think of length option only usage, but I cannot think usage that could > be useful for majority of PHP users like advanced CSRF token. Is this really something we need in our official docs instead of for example on a personal blog? To be honest I am afraid of ending up with something like the current state of the session docs. Which are imo way too broad / opinionated, non English, contains utterly confusing examples and / or flat out wrong and broken examples. Above already resulted in a stream of docs bugs regarding session pages and a lot of confused readers. By all means describe how functions work, but don't confuse readers with things most people won't ever need or are better suited as a (series of) blog posts / Stack Overflow post(s). My €0.02 cc-ing docs discussion to get them also involved in case somebody of the docs team has an opinion. > Andrey, > > Could you give us some length only and length/info only example > that could be useful for most PHP users. > It should be safe and recommended usage. > I suppose you should have some good examples. > > Thank you. > > -- > Yasuo Ohgaki > yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php