Re: [PHP-DEV] Exposing object handles to userland

[Stanislav Malyshev]

Hi!

> - Can two objects can have the same object id
>   but different object handlers?
>   (e.g. iterators of some built in classes?)
>   I'm not familiar enough with PHP's history to be sure.

Yes, if extension using non-standard handlers is in use.

> - Can the the largest object handle be larger
>   than the size of `zend_long` in 32-bit systems?

Handle is uint32_t, so probably no.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Exposing object handles to userland

[tyson andre]

There was a proposal back in 2015 to implement
a function spl_object_id(object $o) : int`,
which directly returns the object handle
(similar to `spl_object_hash`, but as an integer, not a string).
I'm interested in finishing implementing spl_object_id for php 7.2 

I already have working code implementing spl_object_id() at
https://github.com/TysonAndre/php-src/pull/1
The implementation XORs the object handle with the 
exact same random bits that `spl_object_hash` would.

Previous emails from 2015 can be seen here:
- https://marc.info/?t=14383527453&r=1&w=2

Previous comment by a PHP maintainer in support of `spl_object_id()`
- https://marc.info/?l=php-internals&m=143837339210596&w=2

I'm unsure if an RFC is necessary. I have two pending questions.

- Can two objects can have the same object id
  but different object handlers?
  (e.g. iterators of some built in classes?)
  I'm not familiar enough with PHP's history to be sure.
- Can the the largest object handle be larger
  than the size of `zend_long` in 32-bit systems?

Example places where this would be useful:

1. https://marc.info/?l=php-internals&m=143849841618494&w=2

2. I also recently wanted to track a large number of (cloneable)
   small sets of objects in an application that sometimes used a lot of memory,
   and the fact that arrays support copy on write helped save memory
   relative to SplObjectHash if arrays and integer keys were used.
   See https://github.com/etsy/phan/pull/729#issuecomment-299289378

- Tyson Andre (tandre)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates

[Anatol Belski]

> -Original Message-
> From: Niklas Keller [mailto:m...@kelunik.com]
> Sent: Tuesday, July 4, 2017 11:14 PM
> To: Anatol Belski 
> Cc: Sara Golemon ; Jakub Zelenka ; PHP
> Internals 
> Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
> 
>   But the RFC is what you wrote about some days ago. Anything I told is
> based on the RFC and the previous conversations. My understanding was, that
> you were intended to push the exact RFC to vote. If you tell now there's no
> approach and the RFC has to be ignored, then it doesn't help. If there's 
> another
> approach, so please present it.
> 
> 
> Nobody wants to backport OpenSSL's implementation, so I don't see the 
> viability
> of supporting `auth_level`.
> 
> I've outlined my current suggestion several mails ago:
> 
> -
> I think the best approach for now would be that:
> 
> Add two new context options for the "ssl" wrapper:
> "insecure_allow_md5_signature" and "insecure_allow_sha1_signature". They
> will both default to false starting in PHP 7.2 while the backports to PHP 7.1 
> and
> 7.0 will default to true. Additionally there will be two INI options which 
> are only
> added to PHP 7.1 and 7.0 to allow people to immediately upgrade to secure
> defaults without any risk of breaking other apps.
> -
Ok, so that's where the cat catches its tail. If there are both INI and wrapper 
options, doing the same, it were excessive. Say, if the context option has to 
be integrated anyway, why INI? Otherwise, if INI is supposed to provide same 
separately, without touching the code - why bother with stream context? Or in 
further, if the INI is supposed to be ignored in 7.2, then the code still has 
to be changed. The more complicated, the more inconsistent.

Thanks. 

Re: [PHP-DEV] [RFC] [Voting] Class Naming

[Christoph M. Becker]

On 04.07.2017 at 18:44, schrieb Fleshgrinder wrote:

> On 7/1/2017 7:42 PM, Fleshgrinder wrote:
>> https://wiki.php.net/rfc/class-naming
>>
>> Voting starts now and will be open for two weeks (July 15).
>>
> 
> Just to clarify something that came up:
> 
> Voting "no" on the first poll means that we are not going to define a
> rule for class naming. Hence, voting "no" on the first poll and yes on
> anything in the second has no effect!
> 
> This is how all multi-polls so far worked and this one is no exception.

Hmm, one might dislike having the coding standards amended in this
regard, but still may have a preference on how it would be changed, if
the change will be accepted.

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates

[Niklas Keller]

>
> But the RFC is what you wrote about some days ago. Anything I told is
> based on the RFC and the previous conversations. My understanding was, that
> you were intended to push the exact RFC to vote. If you tell now there's no
> approach and the RFC has to be ignored, then it doesn't help. If there's
> another approach, so please present it.


Nobody wants to backport OpenSSL's implementation, so I don't see the
viability of supporting `auth_level`.

I've outlined my current suggestion several mails ago:

-
I think the best approach for now would be that:

Add two new context options for the "ssl" wrapper:
"insecure_allow_md5_signature" and "insecure_allow_sha1_signature". They
will both default to false starting in PHP 7.2 while the backports to PHP
7.1 and 7.0 will default to true. Additionally there will be two INI
options which are only added to PHP 7.1 and 7.0 to allow people to
immediately upgrade to secure defaults without any risk of breaking other
apps.
-

Regards, Niklas

RE: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates

[Anatol Belski]

> -Original Message-
> From: Niklas Keller [mailto:m...@kelunik.com]
> Sent: Tuesday, July 4, 2017 8:21 PM
> To: Anatol Belski 
> Cc: Sara Golemon ; Jakub Zelenka ; PHP
> Internals 
> Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
> 
> 2017-07-04 13:33 GMT+02:00 Anatol Belski   >:
> 
>   An INI option doesn't seem necessary. If there's a stream context
> option, the existing code has to be touched. Those who do it, know what they
> do. Same as with the other issue about TLS - stable branches, that have active
> users already, we shouldn't enforce the change, but just offer it.
> 
> 
> 
> The issue without INI option is that it requires a code change. We can't just 
> tell
> people "better apply this configuration change to have secure TLS". I'd 
> definitely
> want this to be enabled _everywhere_.
> 
> 
>   I'd be also against an INI option in the sense it's being suggested,
> because it would be not useful in 7.2 and above. As you mention also, they may
> have the reverse effect in 7.2.
> 
> 
> We can prevent the reverse effect by ignoring it if it has bad security 
> effects.
> 
> 
>   The current RFC doesn't mention any INI, and I think it's too much
> inconsistency having both ini and stream context.
> 
> 
> Forget about everything that's in the RFC about the actual implementation. 
> It's
> an older idea that needs to be updated based on what's suggested and seems
> acceptable.
> 
But the RFC is what you wrote about some days ago. Anything I told is based on 
the RFC and the previous conversations. My understanding was, that you were 
intended to push the exact RFC to vote. If you tell now there's no approach and 
the RFC has to be ignored, then it doesn't help. If there's another approach, 
so please present it.

Regards

Anatol

Re: [PHP-DEV] /usr/bin/ld: cannot find -lmysqlclient | error: wrong mysql library version or lib not found

[Guillermo Cespedes]

Hi, Johannes

- I have cleaned the build directory.
- "source /etc/profile" globally
- set the values with "shared, mysqlnd”

With the last 3 changes, I have managed to compile PHP.
See diff: 
https://gist.github.com/dertin/8de14e458dd4f0d3acb5f0deff120951/revisions?diff=split
 


I'll try without the shared library.
I do not understand much that it is better, to use or not to use shared 
libraries
mysqlnd VS shared,mysqlnd

I will continue to fix and improve the script.

# /usr/local/php7/bin/php -v
PHP 7.1.6 (cli) (built: Jul  4 2017 18:43:51) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies

# /usr/local/php7/bin/php -i | grep Configure
Configure Command =>  './configure'  '--prefix=/usr/local/php7' 
'--enable-huge-code-pages' 
'--with-config-file-scan-dir=/usr/local/php7/etc/conf.d' '--without-pear' 
'--enable-bcmath' '--with-bz2' '--enable-calendar' '--enable-intl' 
'--enable-exif' '--enable-dba' '--enable-ftp' '--with-gettext' '--with-gd' 
'--with-jpeg-dir' '--enable-mbstring' '--with-mcrypt' '--with-mhash' 
'--enable-mysqlnd=shared' '--with-mysqli=shared,mysqlnd' 
'--with-pdo-mysql=shared,mysqlnd' 
'--with-mysql-sock=/var/run/mysqld/mysqld.sock' '--with-openssl' 
'--enable-pcntl' '--with-pspell' '--enable-shmop' '--enable-soap' 
'--enable-sockets' '--enable-sysvmsg' '--enable-sysvsem' '--enable-sysvshm' 
'--enable-wddx' '--with-zlib' '--enable-zip' '--with-readline' '--with-curl' 
'--enable-simplexml' '--enable-xmlreader' '--enable-xmlwriter' '--enable-fpm' 
'--with-fpm-user=www-data' '--with-fpm-group=www-data’

Thanks for the help.


> El 4 jul. 2017, a las 14:09, Johannes Schlüter  escribió:
> 
> On Di, 2017-07-04 at 13:39 -0300, Guillermo Cespedes wrote:
>> See in: https://lists.launchpad.net/maria-discuss/msg04668.html
> 
> Thanks, the --version output is of course unfortunate, as I can't
> distinguish in a good way between MariaDB and a future MySQL 10, except
> by guessing from program name ... anyways I'll see what I can do.
> 
>> I also tried the following:
>> 
>> --enable-mysqlnd \
>> --with-mysqli=mysqlnd \
>> --with-pdo-mysql=mysqlnd \
>> --with-mysql-sock=/var/run/mysqld/mysqld.sock
>> 
>> It returns an error that can not find mysql_config
> 
> Works nicely for my:system, which doesn't have mysql_config in PATH:
> 
> $ mysql_config
> The program 'mysql_config' is currently not installed. You can install
> it by typing:
> sudo apt install libmysqlclient-dev
> 
> 
> 
> $ sapi/cli/php -v
> PHP 7.1.8-dev (cli) (built: Jul  4 2017 19:05:05) ( NTS )
> Copyright (c) 1997-2017 The PHP Group
> Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies
> 
> $ sapi/cli/php -i | grep Configure
> Configure Command =>  '../../php-7.1/configure'  '--enable-mysqlnd' '
> --with-mysqli=mysqlnd' '--with-pdo-mysql=mysqlnd' '--with-mysql-
> sock=/var/run/mysqld/mysqld.sock'
> 
> Maybe you have old autoconf cache files lying around or such? Can you
> try on a clean tree? If this doesn't help please provide the config.log
> file.
> 
> johannes
> 

Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates

[Niklas Keller]

2017-07-04 13:11 GMT+02:00 Anatol Belski :

> Hi Niklas,
>
> > -Original Message-
> > From: Niklas Keller [mailto:m...@kelunik.com]
> > Sent: Monday, July 3, 2017 7:13 PM
> > To: Anatol Belski ; Sara Golemon 
> > Cc: Jakub Zelenka ; PHP Internals <
> internals@lists.php.net>
> > Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
> >
> > I think the best approach for now would be that:
> >
> > Add two new context options for the "ssl" wrapper:
> > "insecure_allow_md5_signature" and "insecure_allow_sha1_signature". They
> > will both default to false starting in PHP 7.2 while the backports to
> PHP 7.1 and
> > 7.0 will default to true. Additionally there will be two INI options
> which are only
> > added to PHP 7.1 and 7.0 to allow people to immediately upgrade to secure
> > defaults without any risk of breaking other apps.
> >
> Same as Ferenc, I couldn't find anything in other languages but this about
> Java http://openjdk.java.net/jeps/288 . Seems a well thought approach and
> your suggestion about the stream context is similar.
>

I asked in #python-dev on Freenode yesterday. The response I got was that
it's something on the TODO list, but they don't see it as high priority and
the person I talked to said it would only be a defense-in-depth, which it
is not, it's a vulnerability.


> Probably it is the minimum, whereby the JDK has more flexible options and
> more constraints, which might be too flexible for us.Anyway, users are more
> in control about more details, in PHP we still hide many details. For
> example, consider things like `RSA keySize < 1024`, it is solvable in PHP
> with the stream context option, but hardly through INI. And this one is fun
> `SHA1 usage SignedJAR & denyAfter 2017-01-01`, too.
>

Regards, Niklas

Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates

[Niklas Keller]

2017-07-04 13:33 GMT+02:00 Anatol Belski :

> Hi,
>
> > -Original Message-
> > From: Niklas Keller [mailto:m...@kelunik.com]
> > Sent: Monday, July 3, 2017 8:12 PM
> > To: Sara Golemon 
> > Cc: Anatol Belski ; Jakub Zelenka ;
> PHP
> > Internals 
> > Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
> >
> > 2017-07-03 19:24 GMT+02:00 Sara Golemon  >  >:
> >
> >
> >   On Mon, Jul 3, 2017 at 1:12 PM, Niklas Keller  >  > wrote:
> >   > Additionally there will be two INI options
> >   > which are only added to PHP 7.1 and 7.0 to allow people to
> > immediately
> >   > upgrade to secure defaults without any risk of breaking other
> apps.
> >   >
> >   I understand what you're going for there, but it's just a bit
> weird to
> >   have that INI option exist for a weird pair of version ranges and
> not
> >   forward.   I'd say keep the INI in 7.2 and (perhaps) mark them
> >   deprecated.  There's no sense making that upgrade path unreasonably
> >   difficult.
> >
> >
> >
> > True, but I'd like it to be an INI option to strengthen the security,
> but not allow
> > to weaken it. You really shouldn't use MD5 or SHA1 for TLS certificates
> 2018 (!).
> > If you really need it there, you can still set a default stream context
> option, but
> > we won't clutter the INI options of future versions.
> >
> An INI option doesn't seem necessary. If there's a stream context option,
> the existing code has to be touched. Those who do it, know what they do.
> Same as with the other issue about TLS - stable branches, that have active
> users already, we shouldn't enforce the change, but just offer it.
>

The issue without INI option is that it requires a code change. We can't
just tell people "better apply this configuration change to have secure
TLS". I'd definitely want this to be enabled _everywhere_.


> I'd be also against an INI option in the sense it's being suggested,
> because it would be not useful in 7.2 and above. As you mention also, they
> may have the reverse effect in 7.2.


We can prevent the reverse effect by ignoring it if it has bad security
effects.


> The current RFC doesn't mention any INI, and I think it's too much
> inconsistency having both ini and stream context.


Forget about everything that's in the RFC about the actual implementation.
It's an older idea that needs to be updated based on what's suggested and
seems acceptable.


> As linked in the other mail, what we could do is introduce INI options
> only, Java alike, that would control the behavior same way in every branch.
> As much as almost no one likes new INI options, it would mean likely no
> backport were required.


You still need to backport it then.


> A stream context option sounds more plausible and future oriented to me,
> however.


Regards, Niklas

Re: [PHP-DEV] /usr/bin/ld: cannot find -lmysqlclient | error: wrong mysql library version or lib not found

[Johannes Schlüter]

On Di, 2017-07-04 at 13:39 -0300, Guillermo Cespedes wrote:
> See in: https://lists.launchpad.net/maria-discuss/msg04668.html

Thanks, the --version output is of course unfortunate, as I can't
distinguish in a good way between MariaDB and a future MySQL 10, except
by guessing from program name ... anyways I'll see what I can do.

> I also tried the following:
> 
> --enable-mysqlnd \
> --with-mysqli=mysqlnd \
> --with-pdo-mysql=mysqlnd \
> --with-mysql-sock=/var/run/mysqld/mysqld.sock
> 
> It returns an error that can not find mysql_config

Works nicely for my:system, which doesn't have mysql_config in PATH:

$ mysql_config
The program 'mysql_config' is currently not installed. You can install
it by typing:
sudo apt install libmysqlclient-dev



$ sapi/cli/php -v
PHP 7.1.8-dev (cli) (built: Jul  4 2017 19:05:05) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies

$ sapi/cli/php -i | grep Configure
Configure Command =>  '../../php-7.1/configure'  '--enable-mysqlnd' '
--with-mysqli=mysqlnd' '--with-pdo-mysql=mysqlnd' '--with-mysql-
sock=/var/run/mysqld/mysqld.sock'

Maybe you have old autoconf cache files lying around or such? Can you
try on a clean tree? If this doesn't help please provide the config.log
file.

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Voting] Class Naming

[Fleshgrinder]

On 7/1/2017 7:42 PM, Fleshgrinder wrote:
> https://wiki.php.net/rfc/class-naming
> 
> Voting starts now and will be open for two weeks (July 15).
> 

Just to clarify something that came up:

Voting "no" on the first poll means that we are not going to define a
rule for class naming. Hence, voting "no" on the first poll and yes on
anything in the second has no effect!

This is how all multi-polls so far worked and this one is no exception.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] /usr/bin/ld: cannot find -lmysqlclient | error: wrong mysql library version or lib not found

[Guillermo Cespedes]

Hi, Thanks for the reply

# /usr/local/mysql/bin/mariadb_config
# /usr/local/mysql/bin/mysql_config 
# my_print_defaults --mysqld

See in: https://lists.launchpad.net/maria-discuss/msg04668.html 


I also tried the following:

--enable-mysqlnd \
--with-mysqli=mysqlnd \
--with-pdo-mysql=mysqlnd \
--with-mysql-sock=/var/run/mysqld/mysqld.sock

It returns an error that can not find mysql_config

In an hour I'll try:

--enable-mysqlnd=shared \
--with-mysqli=shared,mysqlnd \
--with-pdo-mysql=shared,mysqlnd \
--with-mysql-sock=/var/run/mysqld/mysqld.sock

As indicated here: https://lists.launchpad.net/maria-discuss/msg04674.html 


Regards,

> El 4 jul. 2017, a las 13:10, Johannes Schlüter  escribió:
> 
> Hi,
> 
> On Mo, 2017-07-03 at 19:17 -0300, Guillermo Cespedes wrote:
>> Hi,
>> 
>> I am compiling MariaDB 10.2.6 and PHP 7.1.6
>> 
>> I'm trying it on Debian 8.8 32x / x64 on DigitalOcean
>> 
>> See the script:
>> https://gist.github.com/dertin/8de14e458dd4f0d3acb5f0deff120951
>> 
>> But I have problems compiling PHP with MariaDB
>> 
>> # grep 'mysql’ config.log
> 
> [...]
> 
>> configure:52749: checking for mysql_set_server_option in
>> -lmysqlclient
> 
> The cause for the behavior seems to be that the mysqli/config.m4 file
> checks your the information provided by the "config" program you
> passed, but for feature check uses the hard coded name of libmysql.
> Maybe this could be refactored to a simpler version check and
> discontinue support for versions before 5.0 ... if you send me the
> output from 
> mariadb_config --libs
> and
> mariadb_config --version
> I can see if I can cook up a patch.
> 
> 
> That said: Preferred way is to build using mysqlnd instead of libmysql,
> so just use  --with-mysql and --with-pdo-mysql without path (or, in
> case you like it explicit, =mysqlnd for both) that's the client library
> optimized for PHP.
> See http://php.net/manual/en/mysqlinfo.library.choosing.php
> 
> 
> Also mind that MariaDB is a downstream fork of MySQL and both systems
> are diverting and likely will divert more over time. Experience can
> vary.
> 
> johannes
> 
> Note: I'm a member of Oracle's MySQL engineering team. Personal
> opinions. No promises from Oracle.

Re: [PHP-DEV] /usr/bin/ld: cannot find -lmysqlclient | error: wrong mysql library version or lib not found

[Johannes Schlüter]

Hi,

On Mo, 2017-07-03 at 19:17 -0300, Guillermo Cespedes wrote:
> Hi,
> 
> I am compiling MariaDB 10.2.6 and PHP 7.1.6
> 
> I'm trying it on Debian 8.8 32x / x64 on DigitalOcean
> 
> See the script:
> https://gist.github.com/dertin/8de14e458dd4f0d3acb5f0deff120951
> 
> But I have problems compiling PHP with MariaDB
> 
> # grep 'mysql’ config.log

[...]

> configure:52749: checking for mysql_set_server_option in
> -lmysqlclient

The cause for the behavior seems to be that the mysqli/config.m4 file
checks your the information provided by the "config" program you
passed, but for feature check uses the hard coded name of libmysql.
Maybe this could be refactored to a simpler version check and
discontinue support for versions before 5.0 ... if you send me the
output from 
    mariadb_config --libs
and
    mariadb_config --version
I can see if I can cook up a patch.


That said: Preferred way is to build using mysqlnd instead of libmysql,
so just use  --with-mysql and --with-pdo-mysql without path (or, in
case you like it explicit, =mysqlnd for both) that's the client library
optimized for PHP.
See http://php.net/manual/en/mysqlinfo.library.choosing.php


Also mind that MariaDB is a downstream fork of MySQL and both systems
are diverting and likely will divert more over time. Experience can
vary.

johannes

Note: I'm a member of Oracle's MySQL engineering team. Personal
opinions. No promises from Oracle.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates

[Anatol Belski]

Hi,

> -Original Message-
> From: Niklas Keller [mailto:m...@kelunik.com]
> Sent: Monday, July 3, 2017 8:12 PM
> To: Sara Golemon 
> Cc: Anatol Belski ; Jakub Zelenka ; PHP
> Internals 
> Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
> 
> 2017-07-03 19:24 GMT+02:00 Sara Golemon   >:
> 
> 
>   On Mon, Jul 3, 2017 at 1:12 PM, Niklas Keller   > wrote:
>   > Additionally there will be two INI options
>   > which are only added to PHP 7.1 and 7.0 to allow people to
> immediately
>   > upgrade to secure defaults without any risk of breaking other apps.
>   >
>   I understand what you're going for there, but it's just a bit weird to
>   have that INI option exist for a weird pair of version ranges and not
>   forward.   I'd say keep the INI in 7.2 and (perhaps) mark them
>   deprecated.  There's no sense making that upgrade path unreasonably
>   difficult.
> 
> 
> 
> True, but I'd like it to be an INI option to strengthen the security, but not 
> allow
> to weaken it. You really shouldn't use MD5 or SHA1 for TLS certificates 2018 
> (!).
> If you really need it there, you can still set a default stream context 
> option, but
> we won't clutter the INI options of future versions.
> 
An INI option doesn't seem necessary. If there's a stream context option, the 
existing code has to be touched. Those who do it, know what they do. Same as 
with the other issue about TLS - stable branches, that have active users 
already, we shouldn't enforce the change, but just offer it.

I'd be also against an INI option in the sense it's being suggested, because it 
would be not useful in 7.2 and above. As you mention also, they may have the 
reverse effect in 7.2. The current RFC doesn't mention any INI, and I think 
it's too much inconsistency having both ini and stream context. As linked in 
the other mail, what we could do is introduce INI options only, Java alike, 
that would control the behavior same way in every branch. As much as almost no 
one likes new INI options, it would mean likely no backport were required. A 
stream context option sounds more plausible and future oriented to me, however.

Regards

Anatol

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates

[Anatol Belski]

Hi Sara,

> -Original Message-
> From: p...@golemon.com [mailto:p...@golemon.com] On Behalf Of Sara
> Golemon
> Sent: Monday, July 3, 2017 7:22 PM
> To: Anatol Belski 
> Cc: Niklas Keller ; Jakub Zelenka ; PHP
> Internals 
> Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
> 
> On Mon, Jul 3, 2017 at 12:49 PM, Anatol Belski  wrote:
> > About how to proceed - I'd say the issue is clear and either way
> > should be fixed. The RFC chooses the explicit strength approach.
> > What I'm a bit concerned about is, that there's no implementation by
> > this time, neither for 7.2 nor for lower. Given there are indeed just
> > last moments before the feature freeze, for 7.2 it depends on RMs.
> >
> I've told Niklas on Twitter, but I'll repeat here for the record.  I fully 
> expect a
> rush of last-minute RFCs "urgently" needing an extension of the feature freeze
> deadline.  These come every new release as people are shocked to discover that
> timetables exist.
> 
With issues like this - d'accord. The early pre-release seems to be 
traditionally a peak time.

> IMO any RFC which does not have a merged implementation by July 20th*
> should assume it's not making it into 7.2, however RFCs will be taken on a 
> case-
> by-case basis while in the beta period.  As to this one: It certainly seems
> important that we don't let users blindly ignore terrible certificates.  
> That's a
> false sense of security, and is arguably worse than no security at all.
> 
> I expect to allow this RFC as far out as beta2 ASSUMING the implementation is
> sensible enough to get a passing vote from internals.
> 
> If it moves things along smoother/quicker, I would suggest to constrain this
> discussion as though it were ONLY targeting 7.2, and we can have a separate
> discussion about how/when it should be back-ported to 7.1 and 7.0 since this
> change does represent a (theoretical**) BC break.
> 
IMO for better compatibility, both "new" and "backport" should be seen 
together. It's clear a fix should come ASAP, but I'd see no reason to rush 
without a good consideration. That's why I was asking right about the code, as 
that's the most essential part. It is true, that some breaches are even allowed 
for security reasons, as per Ferenc, so we need to evaluate it by the matters 
of fact.

Thanks

Anatol


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates

[Anatol Belski]

Hi Niklas,

> -Original Message-
> From: Niklas Keller [mailto:m...@kelunik.com]
> Sent: Monday, July 3, 2017 7:13 PM
> To: Anatol Belski ; Sara Golemon 
> Cc: Jakub Zelenka ; PHP Internals 
> Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
> 
> I think the best approach for now would be that:
> 
> Add two new context options for the "ssl" wrapper:
> "insecure_allow_md5_signature" and "insecure_allow_sha1_signature". They
> will both default to false starting in PHP 7.2 while the backports to PHP 7.1 
> and
> 7.0 will default to true. Additionally there will be two INI options which 
> are only
> added to PHP 7.1 and 7.0 to allow people to immediately upgrade to secure
> defaults without any risk of breaking other apps.
> 
Same as Ferenc, I couldn't find anything in other languages but this about Java 
http://openjdk.java.net/jeps/288 . Seems a well thought approach and your 
suggestion about the stream context is similar.

Probably it is the minimum, whereby the JDK has more flexible options and more 
constraints, which might be too flexible for us.Anyway, users are more in 
control about more details, in PHP we still hide many details. For example, 
consider things like `RSA keySize < 1024`, it is solvable in PHP with the 
stream context option, but hardly through INI. And this one is fun `SHA1 usage 
SignedJAR & denyAfter 2017-01-01`, too.

Regards

Anatol

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] LDAP EXOP

[Andreas Heigl]

Am 04.07.17 um 10:19 schrieb Andreas Treichel:
> Hello,
> 
>>> One thing though that I thought about: Chapter 4 of RFC 3062 explicitly
>>> > states that this function should only be available with confidentially
>>> > support like TLS. So perhaps we should check whether the data will be
>>> > transfered via a secure connection and - if not - raise an error?
> 
>> Hum I get the idea but is that really our place? I mean the API won’t
>> prevent you from storing password without hashing for instance.
>> And people can use ldap_modify to change the password without TLS,
>> which is equally dangerous IMO.
>> For me it should be possible, and useful at least for tests.
> 
> Prefer TLS is good, but is TLS also required on internal networks (e.g.
> docker)?

The RFC[1] is pretty strict on that one. "This extension MUST be used
with confidentiality protection, such as Start TLS [RFC 2830]."

So TLS is not a requirement per se but confidentiality protection…

So I wouldn't check whether TLS is in place as f.e. docker might be a
good confidentiality protection as well…

Cheers

Andreas


1. https://www.ietf.org/rfc/rfc3062.txt
> 
> 


-- 
  ,,,
 (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org   http://hei.gl/wiFKy7 |
+-+
| http://hei.gl/root-ca   |
+-+



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: [RFC] LDAP EXOP

[Andreas Treichel]

Hello,


One thing though that I thought about: Chapter 4 of RFC 3062 explicitly
> states that this function should only be available with confidentially
> support like TLS. So perhaps we should check whether the data will be
> transfered via a secure connection and - if not - raise an error?



Hum I get the idea but is that really our place? I mean the API won’t prevent 
you from storing password without hashing for instance.
And people can use ldap_modify to change the password without TLS, which is 
equally dangerous IMO.
For me it should be possible, and useful at least for tests.


Prefer TLS is good, but is TLS also required on internal networks (e.g. 
docker)?



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] LDAP EXOP

[Andreas Heigl]

Hey Côme

Am 04.07.17 um 09:19 schrieb Côme Chilliet:
[...]
> 
> For ldap_exop_passwd, you proposed:
> string|FALSE ldap_exop_passwd(resource $link [, string $user [, string
> $oldPassword [, string $newPassword]]] - The returned string is the new
> password of the user. Either the given newPassword or a newly generated one.
> 
> Does it makes sense to return the newPassword on success when it’s not 
> generated? I think I would prefer if returning a string explicitely means a 
> password was generated, otherwise it gets too confused (3 possible meaning 
> for the returned value!).

I'd always return the new password. In userland users can compare the
password passed in to the returned password to see whether it was
generated or altered in a way. I think it makes it more consistent than
having to check for three values (FALSE, null|'' and a string).

Cheers

Andreas

-- 
  ,,,
 (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org   http://hei.gl/wiFKy7 |
+-+
| http://hei.gl/root-ca   |
+-+



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: [RFC] LDAP EXOP

[Côme Chilliet]

Le mardi 4 juillet 2017, 07:03:20 Andreas Heigl a écrit :
> > In my opinion the code is really ease to read with exceptions.
> > 
> > try {
> > $user = ldap_exop_whoami($link);
> > }
> > catch(Throwable $e) {
> > }
> 
> It definitely is easier to read. But let's not try too much in one go.
> As all of the current extension uses errors I'd currently stick to the
> errors and leave moving to extensions for a later change. Partly to keep
> at least some kind of consistency and partly to not come into the trap
> of moving to extensions completely and therefore breaking BC…

For me moving to exception is an other subject that would need to be treated 
separately.
And I’m not even sure I would vote for that.

> > How is the behavior of the following?
> > 
> > Change $oldPassword of current user to $newPassword?
> > ldap_exop_passwd($link, '', $oldPassword, $newPassword)
> ldap_exop_passwd($link, null, $oldPassword, $newPassword);
> 
> Though passing an empty string should work also with the current code.
> But I'd prefer to pass NULL
> > 
> > Change $oldPassword of $user to empty string? Or random? Or is this an
> > error?
> > ldap_exop_passwd($link, $user, $oldPassword, '');
> 
> IMHO you can't change to an empty string. Because that would be like not
> setting a password at all. I'd restrict that so far that providing an
> empty password will cause the server to generate a random password that
> is then returned.

This change to a random password.

> > My previous suggestion was to split the function into two versions to
> > reduce the amount of arguments.
> > 
> > string|FALSE ldap_exop_passwd(resource $link, string $user, string
> > $newPassword [, string $oldPassword])
> > 
> > string|FALSE ldap_exop_random_passwd(resource $link, string $user [,
> > string $oldPassword])
> 
> I would not do that as it bloats the API in an - in my eyes -
> unnecessary way. Let's stick to one function for changing password…

Yeah same here, one function for each EXOP makes sense and I don’t see the 
point of splitting into two functions.
I don’t like the idea of switching oldpw and newpw order either as it may 
confuse people.

> One thing though that I thought about: Chapter 4 of RFC 3062 explicitly
> states that this function should only be available with confidentially
> support like TLS. So perhaps we should check whether the data will be
> transfered via a secure connection and - if not - raise an error?

Hum I get the idea but is that really our place? I mean the API won’t prevent 
you from storing password without hashing for instance.
And people can use ldap_modify to change the password without TLS, which is 
equally dangerous IMO.
For me it should be possible, and useful at least for tests.

So for the API I will move to 
string|FALSE ldap_exop_whoami(resource $link) - The returned string is
the DN of the currently bound user.

For ldap_exop_passwd, you proposed:
string|FALSE ldap_exop_passwd(resource $link [, string $user [, string
$oldPassword [, string $newPassword]]] - The returned string is the new
password of the user. Either the given newPassword or a newly generated one.

Does it makes sense to return the newPassword on success when it’s not 
generated? I think I would prefer if returning a string explicitely means a 
password was generated, otherwise it gets too confused (3 possible meaning for 
the returned value!).

Côme

signature.asc
Description: This is a digitally signed message part.