Re: [PHP-DEV] rfc concepts

[Sherif Ramadan]

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

[Kelt Dockins]

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

[lp_benchmark_robot]

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

[Yasuo Ohgaki]

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
  
  
   
@@ -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.
+
+  
  
  
   
@@ -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 @@
   
   

+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 @@
   
   

+hash_hmac
 hash_pbkdf2
 RFC 5869
 userland
implementation

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] [RFC][VOTE] Improve hash_hkdf() parameter

[Yasuo Ohgaki]

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
  
  
   
@@ -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.
+
+  
  
  
   
@@ -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 @@
   
   

+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 @@
   
   

+hash_hmac
 hash_pbkdf2
 RFC 5869
 userland
implementation

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] PHP 7.1.4 is available

[David Zuelke]

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

[Joe Watkins]

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

[Jan Ehrhardt]

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

[wout van gils]

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

[wout van gils]

Kan iemand mij eindelijk eens uitschrijven.?

[PHP-DEV] PHP 7.0.18 is available

[Anatol Belski]

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

[Craig Duncan]

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

[Yasuo Ohgaki]

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

[Yasuo Ohgaki]

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

[Pieter Hordijk]

- 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

[PHP-DEV] Quick introduction

[Damian Glinkowski]

Hello,
I'm Damian (wiki username D0niek), I want to write RFC about function
overloading and of course help with other RFC by commenting how I see it
should works.

--
Pozdrawiam, Damian
o^