Re: [PHP-DEV] Disable PEAR by default

[Alice Wonder]

On 2/1/19 5:12 PM, Peter Kokot wrote:

Hello,

On Sat, 2 Feb 2019 at 02:08, Alice Wonder  wrote:

I do not like composer. A problem I have encountered, a project
specifies a version for a dependency.

That version has vulnerability, developer fixed it in newer release, but
composer keeps pulling in the older version because that is what
composer provides.

And it can be the dependency of a dependency of a dependency.

I do not like Composer.

Adding a "recognition page" while cutting PEAR off also seems, well, slimy.


Frankly, this is irrelevant. If you don't use Composer, that's your
choice. PEAR isn't maintained and will cause similar issues all the
time. Not removing this installation option from php-src in the near
future means maintaining patches for all that time this option will be
present in the PHP and shipping separate pear package for all Linux
distributions. I don't like the sound of that.




Many PEAR packages are maintained, and they are globally installed 
meaning when a vulnerability is found, there is one to be fixed and 
everything on the system is fixed.


Composer is like static linking compared to PEAR which is liked shared 
linking.


Yes it's my opinion, it just seems that deprecating it is a reactionary 
decision caused by the current unfortunate situation, but there's no 
reason why Composer will not also have the same issue as the current 
situation. All it takes is hijacking a github account and trojan updates 
are easy to push through composer.


So what problem is this really solving?

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

Re: [PHP-DEV] Disable PEAR by default

[Alice Wonder]

On 2/1/19 5:08 PM, Alice Wonder wrote:

On 2/1/19 3:06 PM, Peter Kokot wrote:

Hello,

On Fri, 1 Feb 2019 at 12:44, Joe Watkins  wrote:


+1

On Fri, 1 Feb 2019 at 12:35, Sebastian Bergmann  
wrote:



Am 01.02.2019 um 12:27 schrieb Nikita Popov:
I would like to suggest that installation of PEAR is disabled by 
default

in

PHP 7.4. PR: https://github.com/php/php-src/pull/3781


+1


Thank you Nikita for the pull request for this. With all the respect
to PEAR project and people behind it, maybe the PEAR itself should be
added to some sort of recognition page in the manual for their
involvement and work on the first installer of PHP code and initial
move into code reuse, open source PHP libraries, and all that. As time
went forward, Composer took over the role of such installer in PHP
community.


I do not like composer. A problem I have encountered, a project 
specifies a version for a dependency.


That version has vulnerability, developer fixed it in newer release, but 
composer keeps pulling in the older version because that is what 
composer provides.


And it can be the dependency of a dependency of a dependency.

I do not like Composer.

Adding a "recognition page" while cutting PEAR off also seems, well, slimy.



"because that is what composer provides." should be "because that is 
what composer specifies."


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

Re: [PHP-DEV] Disable PEAR by default

[Alice Wonder]

On 2/1/19 3:06 PM, Peter Kokot wrote:

Hello,

On Fri, 1 Feb 2019 at 12:44, Joe Watkins  wrote:


+1

On Fri, 1 Feb 2019 at 12:35, Sebastian Bergmann  wrote:


Am 01.02.2019 um 12:27 schrieb Nikita Popov:

I would like to suggest that installation of PEAR is disabled by default

in

PHP 7.4. PR: https://github.com/php/php-src/pull/3781


+1


Thank you Nikita for the pull request for this. With all the respect
to PEAR project and people behind it, maybe the PEAR itself should be
added to some sort of recognition page in the manual for their
involvement and work on the first installer of PHP code and initial
move into code reuse, open source PHP libraries, and all that. As time
went forward, Composer took over the role of such installer in PHP
community.


I do not like composer. A problem I have encountered, a project 
specifies a version for a dependency.


That version has vulnerability, developer fixed it in newer release, but 
composer keeps pulling in the older version because that is what 
composer provides.


And it can be the dependency of a dependency of a dependency.

I do not like Composer.

Adding a "recognition page" while cutting PEAR off also seems, well, slimy.

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

Re: [PHP-DEV] 7.3.1 corruption issue

[Alice Wonder]

On 1/27/19 4:57 PM, Alice Wonder wrote:
I can't file a bug report because I do not know what went run. I only 
know system


php 7.3.1

Site suddenly stopped working.
Apache error log says:

Mon Jan 28 00:45:17.896727 2019] [php7:error] [pid 4117:tid 
140287279617792] [client 73.15.182.232:53028] PHP Fatal error: 
require_once(): Failed opening required 'base.inc.php' 
(include_path='.:/usr/share/pear:/usr/share/php') in 
/srv/[redacted]/www/controller.php on line 2


That include path is interesting, it lists /usr/share/pear:/usr/share/php

I set the include path in Apache config:


   Options FollowSymlinks
   AllowOverride All
   Require all granted
   php_value include_path "/srv/[redacted]/phpinclude:/usr/share/pear"
   AddType application/x-httpd-php-source .phps


I never set include path in my php code.

It looks like the value became corrupted and so it went to a default.

Restarted Apache and everything worked.

How would I find out what corrupted that setting? That sounds dangerous. 
Never happened in php 7.1.x which I ran from start, or in 7.3.0 which I 
also ran from the start. Memory corruption bug?




correction, it reverted to .:/usr/share/pear:/usr/share/php which is 
dangerous, php should not have a default that includes the directory the 
script is running from even though a lot of people like to do that.


When a path is explicitly set to NOT include the current directory, 
including it in a default when the setting becomes corrupt could 
(should?) be considered a security flaw.


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

[PHP-DEV] 7.3.1 corruption issue

[Alice Wonder]

I can't file a bug report because I do not know what went run. I only 
know system


php 7.3.1

Site suddenly stopped working.
Apache error log says:

Mon Jan 28 00:45:17.896727 2019] [php7:error] [pid 4117:tid 
140287279617792] [client 73.15.182.232:53028] PHP Fatal error: 
require_once(): Failed opening required 'base.inc.php' 
(include_path='.:/usr/share/pear:/usr/share/php') in 
/srv/[redacted]/www/controller.php on line 2


That include path is interesting, it lists /usr/share/pear:/usr/share/php

I set the include path in Apache config:


  Options FollowSymlinks
  AllowOverride All
  Require all granted
  php_value include_path "/srv/[redacted]/phpinclude:/usr/share/pear"
  AddType application/x-httpd-php-source .phps


I never set include path in my php code.

It looks like the value became corrupted and so it went to a default.

Restarted Apache and everything worked.

How would I find out what corrupted that setting? That sounds dangerous. 
Never happened in php 7.1.x which I ran from start, or in 7.3.0 which I 
also ran from the start. Memory corruption bug?


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

Re: [PHP-DEV] Re: patch for imap bug 77153

[Alice Wonder]

On 11/20/2018 11:38 PM, Kalle Sommer Nielsen wrote:

Den ons. 21. nov. 2018 kl. 06.13 skrev Pierre Joye :

Btw, is imap on the list to deprecate in 7.x + kill in 8.x? It is really
not maintained well, both c-client and the ext. Would it be possible to
consider it?


I remember we have spoken about this in the past and it seems that
everytime it comes up, is the argument that we don't provide a real
mail alternative. I mean sure there is lots of userland based
implementations and all, but I still think that PHP should provide
something out of the box, but I do agree that at one point, the
security concerns will start to vastly outweight the unmaintained
library, but its really something that should be discussed for a
future release.





To me it is not logical to continue maintaining a wrapper to an 
abandoned library just so the functions continue to exist for the sake 
of existing.


That seems like a bad policy.

Import the library into core and maintain it or write an alternate from 
scratch - IF the functions it provides truly has market demand. 
Otherwise remove support. Those seem to me like the only logical 
options. Nostalgia is not logical.


I just checked my roundcube install, it does not use this wrapper, so 
clearly IMAP connectivity can be obtained through other means.


That makes me feel inclined to believe this wrapper is not needed.

I don't vote, but PHP shouldn't be like OpenSSL was with things like 
heartbeat - an extension almost no one used and seemingly no one 
maintained yet it was everywhere and vulnerable.


Maybe stick the IMAP wrapper in PECL if someone needs it badly enough to 
be willing to maintain the wrapper there.


Less is more, more or less.

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

Re: [PHP-DEV] re2c version(s)

[Alice Wonder]

On 07/17/2018 06:53 PM, Sara Golemon wrote:




I think devs should be able to use flexible versions of re2c (and
other tools, e.g. bison), BUT that we should declare formally what
versions of these build tools will be used on what branches so that
those working on features can predictably know what their changes will
generate.

For example, my builder (which Remi and I both use for 7.2 builds)
currently uses debian:jessie (and therefore re2c 0.13.5 and bison
3.0.2).  Barring any pressing need, we'll plan to keep them at these
versions until 7.2 goes EOL.

-Sara



I really like this, because when packager build systems do need to 
regenerate the files - the build system can package the exact versions 
specified even if just for the build system regardless of the version 
the distro has, and take one possible no matter how unlikely source of 
obscure bugs out of the equation.


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

Re: [PHP-DEV] re2c version(s)

[Alice Wonder]

On 07/13/2018 01:27 PM, Sara Golemon wrote:

On Fri, Jul 13, 2018 at 3:08 PM, Anatol Belski  wrote:


*snip*


Well, whichever version we've settled on, I've updated
sgolemon/php-release to allow using arbitrary versions of re2c.
https://github.com/sgolemon/php-release/commit/9197257bc6f2f607476f950733a0c13ab5e3e867

If RE2C_VERSION is set to 1.0.3, it'll swap in the pre-built 1.0.3
binary I've included in the package.
Otherwise, it'll clone the source repo, checkout the requested tag (or
commit hash) and build that).

I'll plan on doing 7.2.9+ with 1.0.3 (unless we decide differently by then).
Remi should stick to 0.13.5 (default) for 7.2.8-final as previously stated.
Doing a dry-run now to see how it looks.

-Sara



I build 7.1.x packages for CentOS 7 linked against LibreSSL (I don't do 
7.2 because I do every other major release)


I use re2c 0.14.3 because, well, that's what EPEL for CentOS 7 ships.

Is there a real world benefit to upgrading that to the 1.0.3 version in 
my build system? (I suspect relatively easy to do)


Is it likely 7.3 will require newer re2c? My LibreSSL PHP packaging is 
likely switches to 7.3.x branch when 7.3.2 is released.


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

Re: [PHP-DEV] Unifying logical operators

[Alice Wonder]

On 07/10/2018 07:20 PM, Ryan wrote:

On Tue, Jul 10, 2018 at 2:26 AM, Walter Parker  wrote:



That is a matter of style, as I find $a = func() or die more clear that
the version that uses ||

Not chaining stuff together is a third style.

This feels like a Python PEP request. By that I mean that Python wants to
have only one way to do any one task. Perl style is there’s more than one
way to do it.

PHP has been a mix of these styles.

The big question I have is how much PHP code will break due to an enforced
style requirement?.



As I said in the OP, out of the top 30 GitHub repositories (the first page
on the API since I couldn't figure out how to get to the second), there was
only one line that would require a change (and it was copy-pasted from the
manual).  Obviously there's no way to truly know how many times it's used
in non-public code, but I'll expand my GitHub search and report back some
more solid metrics.


Using github may not be the most reliable method.

Look at what is most popularly used in composer dependencies.

For example, I know xor is used in PHP Codesniffer which while likely 
not often part of deployed code is very often a devel dependency.


I think phpunit also uses xor and is also very popular.

I use xor myself but my use is purely hobby (I have a pseudo-RNG written 
in PHP that can take any source of data, random or not, and pass it 
through a filter that makes it pass pRNG tests - showing that passing 
tests doesn't mean a random source is necessarily random enough for 
cryptography)


Anyway as I believe you have already conceded, nuking xor would require 
many projects used a lot to have to change.



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

Re: [PHP-DEV] PHP 2^3

[Alice Wonder]

On 06/25/2018 07:13 AM, Johannes Schlüter wrote:

On Mo, 2018-06-25 at 12:30 +, Zeev Suraski wrote:

3. Foreign Function Interface support.


Related to this on a non-PHP-code and strategic matter I would like to
rethink PECL. Currently maintenance and installing extensions using it
is a pita. This should be doable in a nicer way.
(i.e. pecl pointing directly to Git(Hub) repos, similar to composer, a
way to install precompiled binaries, probably using a more narrow
stable API, better reporting of dependency issues, with the new
execution model of your point 2 also better integration with composer,
...)

johannes



As a packager github is a fracking nightmare.

Frequently what we do is include a hash of the release tarball in our 
build and require that it matches so that people rebuilding our package

(e.g. to add a patch they need) don't have to trust us, they can use our
build spec file but fetch the upstream source themselves, and the hash
matches lets them know that what they fetched from upstream is identical 
to what the initial packager used.


But with github getting the url to the actual download is tricky and 
often breaks and also I've seen the hash from the release tarball on 
github differ from the hash the release tarball on the project site 
numerous times.


git is for code management but when a release it tagged, creation of the 
source tarball should be done by the developer, and released by the 
developer, preferably with sha256 or sha512 sums posted in an easy to 
find location (which github doesn't do)


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

Re: [PHP-DEV] PHP 8 next?

[Alice Wonder]

On 06/23/2018 03:11 PM, Zeev Suraski wrote:




-Original Message-
From: p...@golemon.com [mailto:p...@golemon.com] On Behalf Of Sara
Golemon
Sent: Sunday, June 24, 2018 1:07 AM
To: Nikita Popov 
Cc: PHP internals 
Subject: Re: [PHP-DEV] PHP 8 next?

On Sat, Jun 23, 2018 at 4:22 PM, Nikita Popov  wrote:

Based on some recent conversations, I'm getting the impression that
after PHP 7.3, we might want to go for PHP 8 next.

I'd like to discuss and possibility decide this now, as that would
make PHP
7.3 the last chance to get in deprecations.


Would you mind elaborating on your motivations for a major version bump.  I'm
not saying I disagree in principle, I'm just curious what you're seeing the 
drivers
as.


This is slightly earlier than I intended to bring it up but I do too think that 
the next version beyond 7.3 should be 8.


I disagree.

I'm mostly a user, not a PHP developer.

RHEL 7.5, the latest version of RHEL, still ships 5.4.

Other LTS distributions also probably ship 5.x.

So a major version bump now would mean three major versions of PHP that 
web applications intended to "just work" on enterprise *nix would have 
to support.


If there was a major design flaw in PHP that can only truly be fixed by 
an incompatible version bump past 7 then do it but otherwise, I think it 
would be better to wait until the most recent versions of enterprise 
distributions have moved to php 7.


I'm hoping RHEL 8 does, the benefits are tremendous of 7 over 6.x, but...

The issue is some customers of enterprise linux specifically don't want 
frankenstein systems and want to use vendor supported packages only, and 
I can see their point of view because they pay a lot of money for that 
support.


That being said, I try to get everyone running old PHP up to 7.1 or 7.2 
even if it means frankenstein systems. But some think the benefit of 
enterprise vendor support outweighs the improvements in PHP.



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

Re: [PHP-DEV] Re: PHP7.1.19RC1 ready for testing

[Alice Wonder]

On 06/21/2018 04:02 PM, Dmitri Dmitrienko wrote:


PHP 7.1.19RC1 is ready for testing and can be downloaded from:

https://downloads.php.net/~ab




windows.php.net lists this version as a release
https://windows.php.net/download#php-7.1

same goes to 7.2.7





http://php.net/get/php-7.1.19.tar.xz/from/a/mirror also seems to be 
delivering it but I don't see a published checksum to validate against.


I think they just forgot to make the release note, but I'll wait for a 
published checksum.


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

Re: [PHP-DEV] [RFC][Under Discussion] Add functions array_key_first() and array_key_last()

[Alice Wonder]

On 06/15/2018 08:37 AM, niel wrote:

On 13/06/18 20:26, Enno Woortmann wrote:

Hello internals,

I've changed the status of the currently introduced RFC to add the
functions array_key_first() and array_key_last() to "Under Discussion".

https://wiki.php.net/rfc/array_key_first_last

Regards,

Enno


What is the behaviour if the array does not exist? From the current RFC
it appears it would return null? Wouldn't it be better to return false
for this situation?



I don't like throwing false when something doesn't exist.

apcu does that - returns false instead of null when a record doesn't 
exist, and it is very problematic when the stored value literally is false.


granted a boolean can't be used for an array key, but still, if there 
isn't something to return than null is better than a boolean.


boolean is a value, null is the absence of a value, which is more 
accurate, no?



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

Re: [PHP-DEV] Strict switch statements

[Alice Wonder]

On 06/14/2018 08:57 AM, Thomas Bley wrote:

Nikita Popov wrote on 14.06.2018 10:35:


On Thu, Jun 14, 2018 at 6:53 AM, Sara Golemon  wrote:


Just for casual discussion at this point:
https://github.com/php/php-src/pull/3297

switch ($a) {
  case FOO:
  // Works exactly as current behavior.
  break;
  case == FOO:
 // Nearly identical, though not using the ZEND_CASE optimization.
 // Can probably make this equivalent to `case FOO`, but it felt
like an interesting direction.
 break;
  case === FOO:
 // Only triggers if `$a === FOO`, no type juggling
 break;
}

Love it? Hate it? See obvious flaws?  The implementation is just a
rushed proof of concept, not something I've labored over, it may well
have bugs.  Certainly wouldn't target anything earlier than 7.4, if at
all.



I like the general idea here (switch with strict type comparison), but not
super fond of the particular syntax and implementation.

I think if people want to use strict matching, they'll quite likely want to
have it on all cases. Something like "strict switch ($expr) {}" or "switch
strict ($expr) {}" or "switch (strict $expr) {}" or "switch ($expr) strict
{}" or "switch ($expr) { strict; }" or whatever would be preferable in that
case.

Additionally, switch has the issue of fall-through behavior, which is
somewhat unexpected and error prone to many people. It might make sense to
introduce an entirely new "match" statement that conforms a bit more with
how switch-like strictures are implemented nowadays. That is, something like

match ($expr) {
   "foo" => {...},
   "bar" | "baz" => {...},
}

or similar. This might need some more design work to ensure forward
compatibility with potential future algebraic datatypes etc.

Nikita



for simplicity I would use an extra parameter to have a strict comparison 
(similar to the extra parameter in in_array()):

switch ($a, true) { // strict comparison
switch ($a) { // loose comparison

Regards
Thomas



Should declare(strict_types = 1) do that?

I haven't tried, but I would think it should.

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

Re: [PHP-DEV] [VOTE] Argon2id in Password Hash

[Alice Wonder]

On 06/06/2018 03:54 PM, Charles R. Portwood II wrote:

 Hello Internals,

The RFC for including Argon2id in password_* functions is now open for a
vote. The RFC is available at
https://wiki.php.net/rfc/argon2_password_hash_enhancements.

Voting will be open until June 18th, 2018.

Thank you.

---

Charles R. Portwood II



I don't think I'm allowed to vote but I would say yes - it's already 
available via that sodium extension and I am already using it to replace 
older methods in other webapps (such as WordPress).


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

Re: [PHP-DEV] [VOTE] Deprecate and Remove image2wbmp()

[Alice Wonder]

On 05/26/2018 07:04 AM, Christoph M. Becker wrote:

Hi everybody!

As sequel to the RFC dicussion[1], I have started the vote on the
“Deprecate and Remove image2wbmp()” RFC:



Voting will end on 2018-06-09 21:00 UTC (i.e. in two weeks).  Thanks in
advance for your participation!

[1] 



I am all for deprecating and removing this function.

I would like to see the threshold feature implemented in gd but that's 
different topic entirely.


2-bit color depth may be useful in places where bandwidth is extremely 
limited for some things, though honestly the uses I thought of (e.g. 
company logos) are probably going to be done SVG is concern for 
bandwidth is considered by the web dev, but there's no reason IMHO to 
keep this function when another does the same thing.


Would love to see someone implement a generic threshold algorithm in gd 
though, it definitely has cool used outside of WBMP.


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

Re: [PHP-DEV] [RFC] Deprecation of uniqid()

[Alice Wonder]

On 05/12/2018 03:46 PM, Yasuo Ohgaki wrote:

On Fri, May 11, 2018 at 9:34 PM, Alice Wonder mailto:al...@librelamp.com>> wrote:

slightly better if block

if($more_entropy) {
  sodium_increment($nonce);
  $x = hexdec(substr(bin2hex($nonce),0,12));
  $return = $return . substr($x, 2, 1) . '.' . substr($x, -8);
}

Obvious patterns in the "more entropy" but the output in only
suppose to be unique, not random.


The most important issue in current uniqid() is it could have duplicate
even with $more_entropy=true, since it has

 + 

structure.
System time could be adjusted backwards by ntp, etc.

However changing output by default as follows is enough for it.

 + 


+ random though is expensive if you have to create many at a time, using 
an increment when called multiple times on same page requests results in 
pattern but is less expensive.


So if predictable is okay that's better IMHO and often predictable (with 
a pattern) is okay.


random based on time isn't necessary.

 + 

should be sufficient.


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

Re: [PHP-DEV] [RFC] Deprecation of uniqid()

[Alice Wonder]

On 05/11/2018 05:34 AM, Alice Wonder wrote:

On 05/11/2018 05:10 AM, Alice Wonder wrote:

On 05/11/2018 03:50 AM, Arvids Godjuks wrote:

2018-05-11 12:36 GMT+02:00 Alice Wonder :


On 05/11/2018 01:59 AM, Arvids Godjuks wrote:


2018-05-10 16:33 GMT+02:00 Niklas Keller :

Hey,


I hereby propose to deprecate uniqid(). There have been attempts to
fix
it
(
https://wiki.php.net/rfc/uniqid), but those were rejected during
discussion, because there's no possible fix without breaking BC.
Instead
of
a subtle BC break, this RFC favors the deprecation and moving
users to
other functions.

It's to be discussed whether the function should be removed with
PHP 8.0
or
just deprecated to avoid fully breaking things where it's not
strictly
necessary. A deprecation will probably avoid most new usages,
which is
the
main goal.

RFC: https://wiki.php.net/rfc/deprecate-uniqid

Kind Regards,
Niklas

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


Hello,


as a userland user of this function I do disagree with it's outright
removal. It has it's uses.
What can be done with it is drop the $more_entropy flag and make it
generate at least as long strings and use random_bytes under the
hood for
a
better random.
It can also adopt a length parameter so you can vary the random
part as
much as you need it.

You don't always need a truly random token - I have a system that uses
uniqid to generate tens of thousands tokens per request and it's
actually
a
good thing they are time based at the start of it with a random
part at
the
end (as I said the random part should be improved and get rid of that
stupid dot when generating with $more_entropy = true).



It seems to me that for your use case, you could just use the time()
function to get part of your unique id and then use libsodium to
generated
a nonce for the "random" part, using sodium's function for increment
the
nonce between each use.

Predictable, sure, but your use case says they don't need to be a truly
random token - just unique (essentially a non-random nonce) but with
a time
component.


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



Hello Alice,

Sure, there is lots I can do about that project, including what you have
described. One thing though - client does not need it or want it or
want's
to pay for that work. That whole project is a poster child for a "side
project on a bare minimum, but done by a competent developer instead
of a
student so it actually works in the long run"



Tell the client they can use this for free.

function compat_uniqid(string $prefix='', bool $more_entropy = false)
{
static $nonce = null;
if(is_null($nonce)) {
 $nonce = random_bytes(SODIUM_CRYPTO_SECRETBOX_NONCEBYTES);
}
$m = microtime(true);
$return = sprintf("%8x%05x",floor($m),($m-floor($m))*100);
if($more_entropy) {
sodium_increment($nonce);
$x = hexdec(substr(bin2hex($nonce),0,8));
$x = str_pad($x, 12, "0", STR_PAD_LEFT);
$return = $return . substr($x, 0, 1) . '.' . substr($x, -8);
}
return $prefix . $return;
}



slightly better if block

if($more_entropy) {
  sodium_increment($nonce);
  $x = hexdec(substr(bin2hex($nonce),0,12));
  $return = $return . substr($x, 2, 1) . '.' . substr($x, -8);
}

Obvious patterns in the "more entropy" but the output in only suppose to
be unique, not random.



If you don't need the output to be exact same format, this avoids 
collisions and is faster.


function cryptoUniqid(string $prefix = '', bool $prng = false): string
{
static $nonce = null;
if($prng || is_null($nonce)) {
$nonce = random_bytes(16);
} else {
sodium_increment($nonce);
}
$m = microtime(true);
$return = sprintf("%8x%05x", floor($m), ($m-floor($m))*100);
$return = $return . '.' . base64_encode($nonce);
return $prefix . $return;
}

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

Re: [PHP-DEV] [RFC] Deprecation of uniqid()

[Alice Wonder]

On 05/11/2018 05:34 AM, Alice Wonder wrote:

On 05/11/2018 05:10 AM, Alice Wonder wrote:

On 05/11/2018 03:50 AM, Arvids Godjuks wrote:

2018-05-11 12:36 GMT+02:00 Alice Wonder :


On 05/11/2018 01:59 AM, Arvids Godjuks wrote:


2018-05-10 16:33 GMT+02:00 Niklas Keller :

Hey,


I hereby propose to deprecate uniqid(). There have been attempts to
fix
it
(
https://wiki.php.net/rfc/uniqid), but those were rejected during
discussion, because there's no possible fix without breaking BC.
Instead
of
a subtle BC break, this RFC favors the deprecation and moving
users to
other functions.

It's to be discussed whether the function should be removed with
PHP 8.0
or
just deprecated to avoid fully breaking things where it's not
strictly
necessary. A deprecation will probably avoid most new usages,
which is
the
main goal.

RFC: https://wiki.php.net/rfc/deprecate-uniqid

Kind Regards,
Niklas

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


Hello,


as a userland user of this function I do disagree with it's outright
removal. It has it's uses.
What can be done with it is drop the $more_entropy flag and make it
generate at least as long strings and use random_bytes under the
hood for
a
better random.
It can also adopt a length parameter so you can vary the random
part as
much as you need it.

You don't always need a truly random token - I have a system that uses
uniqid to generate tens of thousands tokens per request and it's
actually
a
good thing they are time based at the start of it with a random
part at
the
end (as I said the random part should be improved and get rid of that
stupid dot when generating with $more_entropy = true).



It seems to me that for your use case, you could just use the time()
function to get part of your unique id and then use libsodium to
generated
a nonce for the "random" part, using sodium's function for increment
the
nonce between each use.

Predictable, sure, but your use case says they don't need to be a truly
random token - just unique (essentially a non-random nonce) but with
a time
component.


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



Hello Alice,

Sure, there is lots I can do about that project, including what you have
described. One thing though - client does not need it or want it or
want's
to pay for that work. That whole project is a poster child for a "side
project on a bare minimum, but done by a competent developer instead
of a
student so it actually works in the long run"



Tell the client they can use this for free.

function compat_uniqid(string $prefix='', bool $more_entropy = false)
{
static $nonce = null;
if(is_null($nonce)) {
 $nonce = random_bytes(SODIUM_CRYPTO_SECRETBOX_NONCEBYTES);
}
$m = microtime(true);
$return = sprintf("%8x%05x",floor($m),($m-floor($m))*100);
if($more_entropy) {
sodium_increment($nonce);
$x = hexdec(substr(bin2hex($nonce),0,8));
$x = str_pad($x, 12, "0", STR_PAD_LEFT);
$return = $return . substr($x, 0, 1) . '.' . substr($x, -8);
}
return $prefix . $return;
}



slightly better if block

if($more_entropy) {
  sodium_increment($nonce);
  $x = hexdec(substr(bin2hex($nonce),0,12));
  $return = $return . substr($x, 2, 1) . '.' . substr($x, -8);
}

Obvious patterns in the "more entropy" but the output in only suppose to
be unique, not random.



My point is that since it is trivial to create a function that is 
compatible with the php function for backwards compatibility, the 
problematic function in php itself doesn't need to exist.


For an actual unique id, code should be updated to generate an actual 
nonce (either with pRNG every call or first time and increment if 
predictable is okay) rather than use a function that clearly fails to 
always produce something unique. So the function should go.


If I had a vote I would vote for the RFC and deprecate it.

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

Re: [PHP-DEV] [RFC] Deprecation of uniqid()

[Alice Wonder]

On 05/11/2018 05:10 AM, Alice Wonder wrote:

On 05/11/2018 03:50 AM, Arvids Godjuks wrote:

2018-05-11 12:36 GMT+02:00 Alice Wonder :


On 05/11/2018 01:59 AM, Arvids Godjuks wrote:


2018-05-10 16:33 GMT+02:00 Niklas Keller :

Hey,


I hereby propose to deprecate uniqid(). There have been attempts to
fix
it
(
https://wiki.php.net/rfc/uniqid), but those were rejected during
discussion, because there's no possible fix without breaking BC.
Instead
of
a subtle BC break, this RFC favors the deprecation and moving users to
other functions.

It's to be discussed whether the function should be removed with
PHP 8.0
or
just deprecated to avoid fully breaking things where it's not strictly
necessary. A deprecation will probably avoid most new usages, which is
the
main goal.

RFC: https://wiki.php.net/rfc/deprecate-uniqid

Kind Regards,
Niklas

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


Hello,


as a userland user of this function I do disagree with it's outright
removal. It has it's uses.
What can be done with it is drop the $more_entropy flag and make it
generate at least as long strings and use random_bytes under the
hood for
a
better random.
It can also adopt a length parameter so you can vary the random part as
much as you need it.

You don't always need a truly random token - I have a system that uses
uniqid to generate tens of thousands tokens per request and it's
actually
a
good thing they are time based at the start of it with a random part at
the
end (as I said the random part should be improved and get rid of that
stupid dot when generating with $more_entropy = true).



It seems to me that for your use case, you could just use the time()
function to get part of your unique id and then use libsodium to
generated
a nonce for the "random" part, using sodium's function for increment the
nonce between each use.

Predictable, sure, but your use case says they don't need to be a truly
random token - just unique (essentially a non-random nonce) but with
a time
component.


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



Hello Alice,

Sure, there is lots I can do about that project, including what you have
described. One thing though - client does not need it or want it or
want's
to pay for that work. That whole project is a poster child for a "side
project on a bare minimum, but done by a competent developer instead of a
student so it actually works in the long run"



Tell the client they can use this for free.

function compat_uniqid(string $prefix='', bool $more_entropy = false)
{
static $nonce = null;
if(is_null($nonce)) {
 $nonce = random_bytes(SODIUM_CRYPTO_SECRETBOX_NONCEBYTES);
}
$m = microtime(true);
$return = sprintf("%8x%05x",floor($m),($m-floor($m))*100);
if($more_entropy) {
sodium_increment($nonce);
$x = hexdec(substr(bin2hex($nonce),0,8));
$x = str_pad($x, 12, "0", STR_PAD_LEFT);
$return = $return . substr($x, 0, 1) . '.' . substr($x, -8);
}
return $prefix . $return;
}



slightly better if block

if($more_entropy) {
  sodium_increment($nonce);
  $x = hexdec(substr(bin2hex($nonce),0,12));
  $return = $return . substr($x, 2, 1) . '.' . substr($x, -8);
}

Obvious patterns in the "more entropy" but the output in only suppose to 
be unique, not random.


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

Re: [PHP-DEV] [RFC] Deprecation of uniqid()

[Alice Wonder]

On 05/11/2018 03:50 AM, Arvids Godjuks wrote:

2018-05-11 12:36 GMT+02:00 Alice Wonder :


On 05/11/2018 01:59 AM, Arvids Godjuks wrote:


2018-05-10 16:33 GMT+02:00 Niklas Keller :

Hey,


I hereby propose to deprecate uniqid(). There have been attempts to fix
it
(
https://wiki.php.net/rfc/uniqid), but those were rejected during
discussion, because there's no possible fix without breaking BC. Instead
of
a subtle BC break, this RFC favors the deprecation and moving users to
other functions.

It's to be discussed whether the function should be removed with PHP 8.0
or
just deprecated to avoid fully breaking things where it's not strictly
necessary. A deprecation will probably avoid most new usages, which is
the
main goal.

RFC: https://wiki.php.net/rfc/deprecate-uniqid

Kind Regards,
Niklas

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


Hello,


as a userland user of this function I do disagree with it's outright
removal. It has it's uses.
What can be done with it is drop the $more_entropy flag and make it
generate at least as long strings and use random_bytes under the hood for
a
better random.
It can also adopt a length parameter so you can vary the random part as
much as you need it.

You don't always need a truly random token - I have a system that uses
uniqid to generate tens of thousands tokens per request and it's actually
a
good thing they are time based at the start of it with a random part at
the
end (as I said the random part should be improved and get rid of that
stupid dot when generating with $more_entropy = true).



It seems to me that for your use case, you could just use the time()
function to get part of your unique id and then use libsodium to generated
a nonce for the "random" part, using sodium's function for increment the
nonce between each use.

Predictable, sure, but your use case says they don't need to be a truly
random token - just unique (essentially a non-random nonce) but with a time
component.


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



Hello Alice,

Sure, there is lots I can do about that project, including what you have
described. One thing though - client does not need it or want it or want's
to pay for that work. That whole project is a poster child for a "side
project on a bare minimum, but done by a competent developer instead of a
student so it actually works in the long run"



Tell the client they can use this for free.

function compat_uniqid(string $prefix='', bool $more_entropy = false)
{
static $nonce = null;
if(is_null($nonce)) {
 $nonce = random_bytes(SODIUM_CRYPTO_SECRETBOX_NONCEBYTES);
}
$m = microtime(true);
$return = sprintf("%8x%05x",floor($m),($m-floor($m))*100);
if($more_entropy) {
sodium_increment($nonce);
$x = hexdec(substr(bin2hex($nonce),0,8));
$x = str_pad($x, 12, "0", STR_PAD_LEFT);
$return = $return . substr($x, 0, 1) . '.' . substr($x, -8);
}
return $prefix . $return;
}

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

Re: [PHP-DEV] [RFC] Deprecation of uniqid()

[Alice Wonder]

On 05/11/2018 01:59 AM, Arvids Godjuks wrote:

2018-05-10 16:33 GMT+02:00 Niklas Keller :


Hey,

I hereby propose to deprecate uniqid(). There have been attempts to fix it
(
https://wiki.php.net/rfc/uniqid), but those were rejected during
discussion, because there's no possible fix without breaking BC. Instead of
a subtle BC break, this RFC favors the deprecation and moving users to
other functions.

It's to be discussed whether the function should be removed with PHP 8.0 or
just deprecated to avoid fully breaking things where it's not strictly
necessary. A deprecation will probably avoid most new usages, which is the
main goal.

RFC: https://wiki.php.net/rfc/deprecate-uniqid

Kind Regards,
Niklas

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



Hello,

as a userland user of this function I do disagree with it's outright
removal. It has it's uses.
What can be done with it is drop the $more_entropy flag and make it
generate at least as long strings and use random_bytes under the hood for a
better random.
It can also adopt a length parameter so you can vary the random part as
much as you need it.

You don't always need a truly random token - I have a system that uses
uniqid to generate tens of thousands tokens per request and it's actually a
good thing they are time based at the start of it with a random part at the
end (as I said the random part should be improved and get rid of that
stupid dot when generating with $more_entropy = true).



It seems to me that for your use case, you could just use the time() 
function to get part of your unique id and then use libsodium to 
generated a nonce for the "random" part, using sodium's function for 
increment the nonce between each use.


Predictable, sure, but your use case says they don't need to be a truly 
random token - just unique (essentially a non-random nonce) but with a 
time component.


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

Re: [PHP-DEV] openssl_pkey_derive

[Alice Wonder]

On 04/20/2018 12:55 PM, Jakub Zelenka wrote:

Hi,

There is a PR to add a new function called openssl_pkey_derive to openssl
extension:

https://github.com/php/php-src/pull/3197

The purpose is to derive public key algorithm shared secret. I think it's a
reasonable addition and if there are no objections, I will merge it in the
next two weeks.

More info can be found in the PR or in the OpenSSL documentation for
EVP_PKEY_derive:

https://www.openssl.org/docs/man1.1.0/crypto/EVP_PKEY_derive.html

Cheers

Jakub



In the next few days I will test it building against LibreSSL - I most 
it might need an ifdef but LibreSSL might support that call, I don't 
know right now. My LibreSSL is actually a tad bit out of date, I will 
update it and try against latest because I know they added some OpenSSL 
stuff to latest.


PHP continuing to build against LibreSSL is very important to me.

Cross-posting reply to their list, hope that is kosher.

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

[PHP-DEV] php and argon2

[Alice Wonder]

In this RFC

https://wiki.php.net/rfc/argon2_password_hash

It looks like Argon2i is now implemented in PHP with the password_* 
functions (though requires a compile flag ???)


Since the sodium extensions used the Argon2id variant by default, would 
it be prudent to make sure the php password_* functions can *verify* 2d 
and 2id variant hashes, even if it does not set them by default?


Real world scenario - WordPress plugin I am working on uses libsodium 
for WordPress password management, upgrading users to Argon2id hashes as 
the log in.


But if that plugin is every removed, those users with upgraded hashes 
then have to do a forgotten password reset because WordPress and PHP 
native functions don't know what to do with a Argon2id hash.


But if PHP knew what to do with it natively, then maybe at least 
WordPress installs on a new enough version of PHP wouldn't have an issue 
when this plugin is installed and then at a later date removed.


Anyway it just seems to me that if even if Argon2i is the only supported 
variant for creating hashes, if the argon2 libraries are going to be 
linked against, it wouldn't be a bad idea to support validating all 
three of the argon2 variants.


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

Re: [PHP-DEV] what's the official position on apache threaded environments

[Alice Wonder]

On 03/21/2018 09:15 PM, Helmut K. C. Tessarek wrote:

On 2018-03-21 21:59, j adams wrote:

So what's the story with PHP and multithreaded environments these days?


Unfortunately PHP was never and will most likely never be threadsafe as
a module.
(Yes, I know that there's the ZTS code, but hey, are you really serious
about this?)
I never understood why the core devs never switched to a threaded model,
but I believe they never deemed it truly necessary.
The ZTS threaded module has a few interesting approaches but fails in
some other areas. To be honest, I suggest to use the fpm-cgi SAPI module
with an Apache threaded environment.


I've been using zts w/ latest apache in threaded and have not found the 
issues, but I've heard Remi mention them and he generally knows all 
things truth from fiction when it comes to php.


Is there a list somewhere of what the specific issues with using zts in 
multi-threaded apache are? What modules have known issues?


I haven't found it.


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

Re: [PHP-DEV] Re: [RFC] Base Conversion Clowniness

[Alice Wonder]

On 03/12/2018 09:43 AM, Sara Golemon wrote:

On Mon, Mar 12, 2018 at 11:32 AM, Christoph M. Becker  wrote:

I tend to prefer option C (throw a Warning, stop processing, and return
the value up to that point).  Option B (throw a Warning and return FALSE
on unexpected characters) might be cleaner, but we're not that picky
elsewhere, and the return value might not even be checked, and thus
easily misinterpreted as zero.


I've also added option D: Throw an exception.


I'm not a computer science guru but that is what I was thinking should 
happen.


The only way bad arguments should get to that point where this issue 
occurs is if the programmer did not properly validate the data.


I don't like that PHP is often very forgiving and recasts types (I guess 
what they call loose type), I personally think if it is appropriate to 
recast the programmer should identify the that it is a safe scenario to 
recast and recast intentionally.


I'm a huge fan of throwing \TypeError from within my own classes when a 
parameter is incorrect and \InvalidArgumentException when the type is 
correct but the argument is absurd.


If it would break code, keep the existing behavior during the next 
release but log a warning - just like is done with deprecation, but the 
release after, I agree throw an exception.


An exception is better than GIGO - an exception lets the coder know they 
have a mistake.



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

Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator

[Alice Wonder]

On 02/12/2018 11:43 AM, Wes wrote:

Again, the reason is: in case in future PHP wants to use backticks for
unicode strings, like javascript.
If the community think it's feasible, in PHP 9, 10, whatever, it must be
deprecated asap.
If you think PHP should use a different syntax for unicode strings in
future, you vote no.
It's as simple as that. I am asking to reserve a particular syntax for
something that could be needed in some years.



backtick to execute a shell command is fairly standard in unix shell 
scripting.


JavaScript is not used for unix shell scripting, php is. Not commonly, 
but I've used it more than once - especially when I already have a php 
class that does something I need to do from a shell script. It's a lot 
faster to write the shell script in PHP than to port the various shell 
scripts to python.


There is no good reason to remove it, and use of a back tick for 
executing shell commands has a long history in many scripting languages.


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

Re: [PHP-DEV] Constants and Access Modifiers

[Alice Wonder]

On 11/12/2017 01:38 AM, Tony Marston wrote:

wrote in message
news:549c4634-ac38-41d3-ab43-f816a9f2b...@fleshgrinder.com...


On 11/12/2017 12:44 AM, Stanislav Malyshev wrote:

Hi!


Yes, Dart has a different understanding of const, which is exactly
why I
posted it for you guys. In the hope that it helps to get more different
views on the topic. Currently you are too concentrated on how it is
implemented in PHP at this time, and argue that it is impossible to
diverge from that path. Which is simply not true, we only have to
ensure
backwards compatibility.


I am not arguing it's impossible, I am arguing it is not a good idea. We
have the concept of constants in this language, and bolting on it a
completely different concept from different language, which by
coincidence was named with the same term, would only be a source of
confusion. If we wanted immutable objects in language - which I am not
convinced at all we do, but assuming for a minute we did - there's no
reason to conflate them with constants as we have them now. These are
different things.



I did not mean to say that we have to have everything exactly as Dart
has it. I just wanted to show, that the meaning of const as we have is
not universally the same.

Abstract constants would also only be truly useful if we could define
the type as well on them. Which is currently not possible. Also, I am
not saying that the requested feature MUST be done with const. However,
it should behave like one, which is impossible with methods.


Just because some languages use a corrupt definition of "constant" is no
reason for PHP to do the same. A constant has a value which, once
defined, cannot be changed. It is not logical to define a constant name
in one place and its value in another.



Plus plus on this. A constant does not change. If it changes it is a 
variable. I do not know anything about Dart but if they are changing the 
meaning of well-defined terms like constant, I worry that there will be 
programs with security holes simply because some developers will not 
understand what they mean by the terms they define.


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

Re: [PHP-DEV] Re: RFC - Array Of for PHP 7

[Alice Wonder]

On 11/07/2017 03:43 AM, Tony Marston wrote:



Irrelevant analogy. If you read
https://en.wikipedia.org/wiki/Reduced_instruction_set_computer you will
see the advantage of getting rid of complex and specialised instructions
and concentrating on simple and general instructions.



You will see some advantages.

There are also advantages to adding things.

Often it is easier for programmers to write secure code when the complex 
stuff they could do in user land is already done for them.


Indeed I believe that is part of the design decisions in TLS 1.3.

It's not just that programmers are lazy and want fewer keystrokes, it is 
more likely for the end developer to have fewer mistakes and properly 
maintain his code when the complex stuff isn't his or her worry.


That's not the right solution all the time, but it also isn't the wrong 
solution all the time.


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

Re: [PHP-DEV] Re: RFC - Array Of for PHP 7

[Alice Wonder]

On 11/07/2017 02:21 AM, Tony Marston wrote:



Some things are so obvious that they do not need scientific proof.


Some things that appear obvious are incorrect, especially when bias 
enters. Scientific proof brings human bias out of the equation, or at 
least reduces it.



For
example, in a motor vehicle the power-to-weight ratio is important as it
affects engine performance and fuel economy. In other words, for a given
engine size the lower the weight of the car and the better the fuel
consumption. The more weight you add the lower the performance. Your car
has a heater which you only use when it's cold. It also has an air
conditioner for when it's hot. It has windscreen wipers, and a motor,
for when it's raining. When the temperature is mild and it's not raining
it means that you are not using any of this equipment, yet you are still
carrying their weight, and this weight is affecting your car's
performance. I do not have to supply any figures as proof as the car
manufacturers keep telling us that cars that weigh less perform better,
which is why they try to reduce the weight of as any components as
possible.


You then give an example for which every first year physics students has 
done experiments which use science to demonstrate it (namely 
demonstrating how weight impacts friction)


Sorry but if something is obvious then it should be able to test in a 
scientific experiment.


It use to be obvious that some animals were closely related until 
scientific tests were done, showing that they weren't, and we discovers 
convergent evolution.


Sorry, I don't mean to go off topic, but saying the scientific method 
isn't needed to back up certain claims because they are obvious is a 
very dangerous point of view.



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

Re: [PHP-DEV] TLS v1.2 -only- deployments

[Alice Wonder]

On 05/11/2017 07:05 AM, Alice Wonder wrote:

On 05/11/2017 04:08 AM, Anatol Belski wrote:

Hi Thomas,


-Original Message-
From: Thomas Hruska [mailto:thru...@cubiclesoft.com]
Sent: Tuesday, May 9, 2017 5:33 PM
To: PHP Development 
Subject: [PHP-DEV] TLS v1.2 -only- deployments

Over the past two weeks, I've observed quite a bit of PHP 7+ userland
code
breaking due to remote hosts switching to a TLS 1.2 only policy.
For various specific reasons, I strongly suspect that PCI DSS 3.1
implementations
or compliance audits against that spec have something to do with the
changes
that I'm seeing:

https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls

In just the last two weeks, I've seen completely unrelated servers of
various
vendors go offline for an upgrade.  When they come back up a short
bit later,
they are suddenly configured for TLS 1.2 only.  Running a Qualys SSL
labs test
confirms the changes.  It's a rather specific change to encounter in
such a short
period of time.

PHP userland code (e.g. stream_socket_client()) is unable to connect
to such
hosts via "tls://" host strings.  The string has to be updated to use
the version-
specific string "tlsv1.2://" before the connecting code starts
working again.


What were interesting is to know some exact servers you mention to
verify, if it were possible to call them by name. In general, probably
having some reliable stats on the matter were not bad. Particularly
with the reason you suspect - so if the changes are driven by the
payment branch, they probably should be respected by both apps and
servers. If some server providers do changes suddenly, thus breaching
customer apps, we need to evaluate the extent of the breach. Fe stats
linked by the Qualys labs itself tell there are still over 90% of of
about 140 000 servers supporting TLS 1.0. OFC. Though, there are some
billions of servers around the globe, so not sure how the stats are
representative. I think in any case, especially if apps are branch
specific, explicit TSL 1.2 is probably the best way, like anything
explicit in security.

Regards

Anatol



I won't list them here because they are not the kind of sites
appropriate for a list, but I am doing this with servers I admin.

My current policy is that with every cert that expires (I generate new
keys/certs yearly), when I bring the new cert into service, it is TLS
1.2 only. And with an extremely limited list of allowed ciphers.

TLS 1.0 is old and at this point, the only browsers that do not support
TLS 1.2 with the limited ciphers I allow are browsers that are no longer
even getting security updates from their vendors.

As such there is no point in continued support of them, and supporting
deprecated clients is dangerous.



This one is safe for the list if people want to know what the TLS 1.2 
only sites look like on ssllabs


https://www.ssllabs.com/ssltest/analyze.html?d=deviant.email

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

Re: [PHP-DEV] TLS v1.2 -only- deployments

[Alice Wonder]

On 05/11/2017 04:08 AM, Anatol Belski wrote:

Hi Thomas,


-Original Message-
From: Thomas Hruska [mailto:thru...@cubiclesoft.com]
Sent: Tuesday, May 9, 2017 5:33 PM
To: PHP Development 
Subject: [PHP-DEV] TLS v1.2 -only- deployments

Over the past two weeks, I've observed quite a bit of PHP 7+ userland code
breaking due to remote hosts switching to a TLS 1.2 only policy.
For various specific reasons, I strongly suspect that PCI DSS 3.1 
implementations
or compliance audits against that spec have something to do with the changes
that I'm seeing:

https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls

In just the last two weeks, I've seen completely unrelated servers of various
vendors go offline for an upgrade.  When they come back up a short bit later,
they are suddenly configured for TLS 1.2 only.  Running a Qualys SSL labs test
confirms the changes.  It's a rather specific change to encounter in such a 
short
period of time.

PHP userland code (e.g. stream_socket_client()) is unable to connect to such
hosts via "tls://" host strings.  The string has to be updated to use the 
version-
specific string "tlsv1.2://" before the connecting code starts working again.


What were interesting is to know some exact servers you mention to verify, if 
it were possible to call them by name. In general, probably having some 
reliable stats on the matter were not bad. Particularly with the reason you 
suspect - so if the changes are driven by the payment branch, they probably 
should be respected by both apps and servers. If some server providers do 
changes suddenly, thus breaching customer apps, we need to evaluate the extent 
of the breach. Fe stats linked by the Qualys labs itself tell there are still 
over 90% of of about 140 000 servers supporting TLS 1.0. OFC. Though, there are 
some billions of servers around the globe, so not sure how the stats are 
representative. I think in any case, especially if apps are branch specific, 
explicit TSL 1.2 is probably the best way, like anything explicit in security.

Regards

Anatol



I won't list them here because they are not the kind of sites 
appropriate for a list, but I am doing this with servers I admin.


My current policy is that with every cert that expires (I generate new 
keys/certs yearly), when I bring the new cert into service, it is TLS 
1.2 only. And with an extremely limited list of allowed ciphers.


TLS 1.0 is old and at this point, the only browsers that do not support 
TLS 1.2 with the limited ciphers I allow are browsers that are no longer 
even getting security updates from their vendors.


As such there is no point in continued support of them, and supporting 
deprecated clients is dangerous.


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

Re: [PHP-DEV] Re: PHP 7.0 and openssl 1.1

[Alice Wonder]

Actually I found that wasn't the case. To build php against an alternat 
openssl API - I did have to rebuild net-snmp but curl, for example, at 
least on CentOS uses NSS for it's TLS and so didn't need to be rebuild 
to build PHP against a different OpenSSL API.


Building in mock, the only php dependency that had an OpenSSL API 
dependency was net-snmp. And if I kept the same API for net-snmp, I 
didn't have to replace the system net-snmp for php to work properly - 
only the net-snmp used in mock.


That was php 5.6.x and 7.1.x though, 7.0.x may have different results, 
but I doubt it.


On 01/23/2017 02:05 AM, Rasmus Lerdorf wrote:

On Mon, Jan 23, 2017 at 12:31 AM, Alice Wonder mailto:al...@librelamp.com>> wrote:

If someone on such a distro really can't use PHP 7.1.x, LibreSSL can
be installed in parallel to OpenSSL (I do on CentOS) and I suspect
php 7.0 will build against it (5.6.x does and 7.1.x does)

Also, I suspect older OpenSSL shared libraries could probably be
installed in parallel.

So it can be done if really needed.


Yes, of course it can be done with a bit (or a lot depending on the
distro) fiddling.
And it is also rather tricky to build against libressl or a different
version of openssl
because we have things like libcurl, libpq, libc-client and probably a
few others as
well that are linked against the system openssl library. You will need
to built alternative
versions of those too.
And for libressl, even if you get it built, you are going to see quite a
few test failures.
This is the current state of make test TESTS=ext/openssl when PHP-7.0 is
built against
the latest version of libressl:

Number of tests :  10598
Tests skipped   :7 (  6.7%) 
Tests warned:0 (  0.0%) (  0.0%)
Tests failed:   32 ( 30.5%) ( 32.7%)
Expected fail   :0 (  0.0%) (  0.0%)
Tests passed:   66 ( 62.9%) ( 67.3%)
-
Time taken  :  446 seconds
=

=
FAILED TEST SUMMARY
-
#46127, openssl_sign/verify: accept different algos
[ext/openssl/tests/bug46127.phpt]
Bug #48182: ssl handshake fails during asynchronous socket connection
[ext/openssl/tests/bug48182.phpt]
Bug #54992: Stream not closed and error not returned when SSL CN_match
fails [ext/openssl/tests/bug54992.phpt]
Bug #65538: SSL context "cafile" supports stream wrappers
[ext/openssl/tests/bug65538_001.phpt]
Bug #65538: SSL context "cafile" disallows URL stream wrappers
[ext/openssl/tests/bug65538_002.phpt]
Bug #65538: SSL context "cafile" supports phar wrapper
[ext/openssl/tests/bug65538_003.phpt]
Bug #65729: CN_match gives false positive when wildcard is used
[ext/openssl/tests/bug65729.phpt]
Bug #68265: SAN match fails with trailing DNS dot
[ext/openssl/tests/bug68265.phpt]
Bug #68879: Match IP address fields in subjectAltName checks
[ext/openssl/tests/bug68879.phpt]
Bug #68920: peer_fingerprint input checks should be strict
[ext/openssl/tests/bug68920.phpt]
Bug #69215: Crypto servers should send client CA list
[ext/openssl/tests/bug69215.phpt]
Bug #72165 Null pointer dereference - openssl_csr_new
[ext/openssl/tests/bug72165.phpt]
Bug #73072: Invalid path SNI_server_certs causes segfault
[ext/openssl/tests/bug73072.phpt]
capture_peer_cert context captures on verify failure
[ext/openssl/tests/capture_peer_cert_001.phpt]
openssl_error_string() tests
[ext/openssl/tests/openssl_error_string_basic.phpt]
Testing peer fingerprint on connection
[ext/openssl/tests/openssl_peer_fingerprint_basic.phpt]
Peer verification enabled for client streams
[ext/openssl/tests/peer_verification.phpt]
Peer verification matches SAN names
[ext/openssl/tests/san_peer_matching.phpt]
Capture SSL session meta array in stream context
[ext/openssl/tests/session_meta_capture.phpt]
sni_server [ext/openssl/tests/sni_server.phpt]
Basic bitwise stream crypto context flag assignment
[ext/openssl/tests/stream_crypto_flags_001.phpt]
TLSv1.1 and TLSv1.2 bitwise stream crypto flag assignment
[ext/openssl/tests/stream_crypto_flags_002.phpt]
Server bitwise stream crypto flag assignment
[ext/openssl/tests/stream_crypto_flags_003.phpt]
Specific protocol method specification
[ext/openssl/tests/stream_crypto_flags_004.phpt]
TLS server rate-limits client-initiated renegotiation
[ext/openssl/tests/stream_server_reneg_limit.phpt]
Verify host name by default in client transfers
[ext/openssl/tests/stream_verify_peer_name_001.phpt]
Allow host name mismatch when "verify_host" disabled
[ext/openssl/tests/stream_verify_peer_name_002.phpt]
Host name mismatch triggers error
[ext/openssl/tests/stream_verify_peer_name_003.phpt]
Specific crypto method for ssl:// transports.
[ext/openssl/tests/streams_crypto_meth

Re: [PHP-DEV] Re: PHP 7.0 and openssl 1.1

[Alice Wonder]

If someone on such a distro really can't use PHP 7.1.x, LibreSSL can be 
installed in parallel to OpenSSL (I do on CentOS) and I suspect php 7.0 
will build against it (5.6.x does and 7.1.x does)


Also, I suspect older OpenSSL shared libraries could probably be 
installed in parallel.


So it can be done if really needed.

On 01/22/2017 07:24 PM, Rasmus Lerdorf wrote:

Ok, I thought perhaps the changes for just openssl-1.1 api compatibility
would be easier to separate out, but I guess not. I did have a look at it
and you are right, while some of the changes are trivial, others are more
involved. Fedora 26, and I would guess any Linux distro release that comes
out this year, will ship with openssl-1.1 so they will not be able to run
any version of PHP prior to 7.1.

-Rasmus

On Sun, Jan 22, 2017 at 11:33 AM, Jakub Zelenka  wrote:


Hi Rasmus,

On Sun, Jan 22, 2017 at 1:28 AM, Rasmus Lerdorf 
wrote:


Jakub, what do you think about back-porting the openssl-1.1 supporting
changes to the PHP-7.0 branch? I think it is too early to have PHP-7.0 not
compile on new Linux versions and right now it doesn't compile on any Linux
that has openssl-1.1.



The thing is that the patch required quite a lot of changes and it was
based on the AEAD and OpenSSL error storing changes so the it changed quite
a lot of code. So all changes together makes some difference between 7.0
and 7.1:

[jakub@localhost 71]$ git diff --stat PHP-7.0 ext/openssl/*.[c,h]
 ext/openssl/openssl.c | 1991 ...
 ext/openssl/php_openssl.h |   25 ...
 ext/openssl/xp_ssl.c  |  199 ...
 3 files changed, 1613 insertions(+), 602 deletions(-)

This shows just openssl ext source files but there are some other changes
for phar and some tweaks in tests.

For that reason I decided that it will be better to target just 7.1 to
have full QA cycle which was a good decision because I needed to fix few
things in beta and rc.

It means that the back-port would require some work to extract just the
porting bits and all test it. It might be slightly trickier as 7.0 still
support 0.9.8 which might complicate things a bit. Also there is still one
failing SNI tests that needs some looking and couple of things needs a look
as well so the port is still not 100% complete. In general I'm not so sure
if it's really worth it to invest too much time into back-porting it as I'm
not sure how many users would really appreciate it (meaning how many users
are not able to update to PHP 7.1 and need to use OpenSSL 1.1.). It might
be also quite a big patch for the point release but if RM is ok with that
and someone wants to spend that time on porting it, I can do the review.
Personally I have got some other stuff on my list (including finishing the
port in 7.1 and some other OpenSSL fixes) so won't probably have time for
anything else than review.

Cheers

Jakub






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

Re: [PHP-DEV] http://php.net/usage.php

[Alice Wonder]

On 01/08/2017 03:51 PM, Stanislav Malyshev wrote:

Hi!

With all this wonderful new year's work going on, should we also update
(or remove, if we don't want to update it anymore)
http://php.net/usage.php ? With data from 2013 it looks kind of pathetic :)



Oh wow yeah, that IMHO needs to go.

I've never been fond of those kind of statistics anyway, often the 
popular product is the product that puts money into marketing and isn't 
really any better (sometimes far worse) than the competition quality- 
and security-wise.


PHP at this point is extremely well established as an enterprise capable 
server-side scripting language.


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

Re: [PHP-DEV] PHP 5.6 end of active support

[Alice Wonder]

On 12/14/2016 02:29 PM, Ferenc Kovacs wrote:

On Wed, Dec 14, 2016 at 2:05 PM, Niklas Keller  wrote:


2016-12-14 12:23 GMT+01:00 Christoph M. Becker :


Hi!

The end of active support for PHP 5.6 is documented to be on December,
31th[1].  Does that mean that there'll be no further release with
"normal" bug fixes (but only security fixes)?

[1] 



It has support until the end of the year, so I guess there will be one
more release with regular fixes in early January.

Regards, Niklas



yep, that's my plan, and the PHP-5.6 branch will be closed for regular
bugfixes after tagging 5.6.30RC1:
http://git.php.net/?p=karma.git;a=blob;f=hooks/pre-receive;h=fdff955c6b13c434aab40cb35cf002ab7c7eb146;hb=HEAD#l32
from that point on only RMs can push changes to the PHP-5.6 branch.
going into extended support also means that there won't be RCs as we don't
have regular bugfixes and we won't have a release each month, only when
there are security fixes ready to be released for 5.6



I want to say a huge thank you for doing this. When 5.6.0 was new I 
moved all sites I am responsible for to it, and I have started porting 
my other sites to 7.1 but haven't finished yet. This gives me a few 
months to make sure everything really does work as intended.


5.6.x IMHO was a fantastic branch throughout and I thank all the devs 
for it as I look forward to 7.1


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

Re: [PHP-DEV] Re: Bumping minimal OpenSSL version to 1.0.1 in master for PHP 7.1

[Alice Wonder]

On 12/13/2016 02:31 AM, Niklas Keller wrote:

OpenSSL support for 1.0.1 will end this year.

Support for version 1.0.1 will cease on 2016-12-31. No further releases of

1.0.1 will be made after that date. Security fixes only will be applied to
1.0.1 until then.
Version 1.0.0 is no longer supported.
Version 0.9.8 is no longer supported.



We dropped 0.9.8 and 1.0.0 in 7.1.

Should we drop support for 1.0.1 in master, so it's dropped for 7.2 then,
as it will be unsupported then?

Regards, Niklas



Will support also then be dropped for LibreSSL? It was forked from 1.0.1g

Right now it is a minority player but I really prefer it over OpenSSL.

I can discuss why but there are lots of discussions on that if the 
points aren't already heard.


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

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

[Alice Wonder]

On 11/20/2016 02:32 PM, Rowan Collins wrote:



I'm not sure what you mean by "political". The big challenge which comes
up again and again, is that take up of new versions of PHP is low. You
can blame the users for that if you like, but the reality is there's no
point rushing your shiny feature into a release that 90% of the user
base won't install.



For the perspective of a user on this -

I always skip a major version. I'm running 5.6.x on my productions, and 
preparing for 7.1 I am running 7.1.0RC on one test server and my 
workstation. I'll probably run 7.1 on production fairly soon after 
release but likely skip 7.2.


I skip because once I have a web application deployed, I'm not looking 
to change it for awhile, security updates sure but I don't need to run 
the latest major release when the release I have works fine.


I suspect many are the same way, and I don't see that as a bad thing.

Releases no longer maintained by upstream obviously should not be run, 
but if the release one has works for the purpose, what problem is solved 
by upgrading to latest major release? It's time consuming and expensive 
because there is always code that needs to be changed and tested.


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

Re: [PHP-DEV] Re: [RFC] Abolish 50%+1 Votes

[Alice Wonder]

On 11/18/2016 06:55 PM, Kalle Sommer Nielsen wrote:

2016-11-19 3:39 GMT+01:00 Alice Wonder :

Is it required to be a member of this list to vote? That too would be a good
idea if it isn't required, hopefully translators are accurate enough to
understand arguments here pro and con when not in a language the voter has
excellent grasp of.


Only people with active VCS accounts or wiki accounts (that's been
approved) are allowed to vote.





Thank you, I knew there was an identity validation requirement, and that 
makes sense.


I do know I enjoy reading the RFC discussions here on what is proposed 
to be deprecated, it often has helped me realize there is a better way 
to do something than the way I currently am doing something.


mcrypt for example, after reading about how stale it was, I didn't wait 
to deprecate it on my own but just removed it from my php build - and 
any web apps I install that want it, I fix.


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

Re: [PHP-DEV] Re: [RFC] Abolish 50%+1 Votes

[Alice Wonder]

On 11/18/2016 06:26 PM, Marcio Almada wrote:



Hi Yasuo,

In my opinion, this belongs to another RFC. Please, propose an optional way
for voters to input a small paragraph disclosing a justification upon
voting. We've seen many voices on this mailing list supporting this
proposal, perhaps it's time to discuss officially. Keep in mind this change
in the voting process requires the voting doodle to be customized somehow
(I don't know how).

Best regards,
Márcio.



Explaining why someone votes against something makes voting against more 
difficult than voting for.


I would suggest just increasing the margin to pass. That's a good way to 
solve the issue, and the pros and cons can be discussed on the list.


Is it required to be a member of this list to vote? That too would be a 
good idea if it isn't required, hopefully translators are accurate 
enough to understand arguments here pro and con when not in a language 
the voter has excellent grasp of.


Personally I abstain from voting because I do not feel qualified to make 
decisions that impact the majority of PHP users, but some things I may 
comment on, but only on this list.



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

Re: [PHP-DEV] Type locked variables

[Alice Wonder]

On 11/15/2016 03:44 PM, Michael Morris wrote:

Perhaps it's time to revisit the idea of allowing variables to have their
types locked down. The keywords needed are already reserved. So...

string $a = "hello";
int $b = 5;

Once declared this way the variable's type won't change unless it gets
unset.


++


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

Re: [PHP-DEV] function overloading

[Alice Wonder]

On 11/15/2016 08:13 AM, Dominic Grostate wrote:

I think this may have been discussed before, but I was largely dismissed
because no one though it would be possible to implement.

However assuming it is possible, what is the general feeling towards
function overloading, as seen in C# and Java?


*snip*

I don't understand what problem it actually solves.

For me, my short term memory isn't very good and some text editors let 
me type a function name and they show the arguments with symantic 
arguments names and that is really beneficial becomes sometimes I forget 
whether $needle comes before $haystack or vice versa.


Those hints are harder to do with function overloading because the 
editor has to then also guess how the function is being used which the 
editor can not easily do.


It just seems to make things more difficult without solving a problem. 
To me anyway.



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

Re: [PHP-DEV] DateTime microseconds discussion

[Alice Wonder]

On 11/08/2016 04:16 AM, Arjen Schol wrote:

Hi Dan,

I think you make some bad assumptions here. The examples provided by
Sjon are scripts submitted to 3v4l.org They may have bad assumptions,
but are real life examples of DateTime usage. And they will break.


They are already broken. That's the point.

Rarely will the current breakage trigger but it will trigger.

Personally I prefer it when bad code obviously triggers, it can be very 
difficult (read expensive) to track bugs in code that only rarely and 
randomly trigger.



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

Re: [PHP-DEV] OpenSSL - New Defaults

[Alice Wonder]

On 11/07/2016 04:29 AM, Nikita Nefedov wrote:
*snip*





Hey,

It might make even more sense to not provide a default here at all. As history 
shows that those methods that are considered secure today can become 
less-than-desirably secure in a couple of years. Which means the same cycle of 
deprecation/changing defaults in years to come.



100% agree

One of the problems that OpenSSL had is that it kept too much for 
compatability with software that hadn't updated to use more modern more 
secure protocols. Hence it supported SSLv3 for forever even long after 
it was no longer really needed, supported things like heartbeat enabled 
by default even though less than 1% of users had any need for the 
extension, etc.


Keeping things secure means breaking software that doesn't keep up to 
date. That's just the way of things.


I confess it bothers me that mcrypt is only being depricated in 7.1 and 
not removed, for example, and that there are plans to continue it as a 
PECL module. It's a dead project, dead security projects are not secure.


Using defaults can be dangerous too, when a system administrator doesn't 
have to think about it because the defaults "work" they often don't, 
even though the way the defaults "work" is often less than ideal.


All the dangerous WordPress plugins out there are ample evidence of 
that, where they default to executing shell commands so that they "work" 
in the event the server doesn't have the right PHP extension available - 
or all the php image processing modules using ImageMagick that by 
default worked with everything under the sun and thus were vulnerable to 
CVE-2016–3714 when they could have (should have) required the admin 
specify a whitelist of image types it accepted.


Anyway that's my viewpoint - screw compatibility when it comes to 
security, and don't use defaults that can cause security issues when the 
admin chooses not to think about the security implications.


Hope this isn't just seen as noise, if it is, I apologize.

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

Re: [PHP-DEV] Allow Iterator to be used with current, next, reset, key functions

[Alice Wonder]

On 10/30/2016 10:19 AM, Rowan Collins wrote:



- deprecate reset(), end(), each(), and key()
- introduce array_first(), array_last(), array_first_key() and
array_last_key()
- document replacements for whatever other use cases we can find
examples of



As a user I certainly like those names better. Semantic function names 
are a definite win in my view.



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

Re: [PHP-DEV] [VOTE] Deprecate png2wbmp() and jpeg2wbmp()

[Alice Wonder]

On 10/30/2016 02:30 PM, Christoph M. Becker wrote:

Hi!

As there has been no discussion in the RFC's discussion thread[1], I
assume there is nothing to discuss, so I've just put the "Deprecate
png2wbmp() and jpeg2wbmp()" RFC[2] to voting.  The voting period ends on
2016-11-13, 22:00 UTC.

Thanks in advance for voting!

[1] 
[2] 



from second link

``format conversion functions available in ext/gd what makes them rather 
special'' probably should read


``format conversion functions available in ext/gd which makes them 
rather special''


(I do that all the time, brain thinks one word and fingers type another)

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

Re: [PHP-DEV] Allow Iterator to be used with current, next, reset, key functions

[Alice Wonder]

On 10/30/2016 05:31 AM, Rasmus Schultz wrote:

On second thought, I agree with that - changing reset() and end()
doesn't make sense, because people know them and expect them to work
in a certain way. Likely a lot of people would actually continue to
use them with intermediary variables the way they do today.


Today?

In PHP 5.6.x I didn't have to use intermediate variables.

Being required to use them was new with PHP 7 and I suspect you will 
find a lot of sites still using pre 7 because they haven't taken the 
time to make sure every app they run works in PHP 7.


All my production servers still run 5.6.x for that reason, I'm only now 
starting to port the apps I can now that it appears the PECL modules I 
need have finally all been updated.


The php apps I am fixing are currently littered with code like this:


$SEVENFIX = explode('.', $rs[0]->cover);
if(end($SEVENFIX) == "whatever") {
  // do stuff
}

before trying the app in my 7.1.0RCx test servers they worked just fine as

if(end(explode('.', $rs[0]->cover)) == "whatever") {
  // do stuff
}

So I suppose some people might "continue" to use them with intermediary 
but a lot of code that hasn't been ported to 7 doesn't currently.


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

[PHP-DEV] 7.1.0RC5 patch

[Alice Wonder]

Hi, first post to list.

LibreSSL user.

PHP 7.1.0RC5 just needs one minor patch to work with LibreSSL, attached

Justification -

X509_get_signature_nid() was introduced in OpenSSL 1.0.2 but LibreSSL 
fork is prior to that.


However (and I don't like this) LibreSSL uses a OPENSSL_VERSION_NUMBER 
defined as 0x2000L


So have to check for presence of LIBRESSL_VERSION_NUMBER when using 
functions introduced to OpenSSL after the fork (1.0.1h I think)


Tested building against LibreSSL 2.4.3 on a CentOS 7 system (where 
OpenSSL has been completely removed) - 7.1.0RC5 compiles and works with 
that line changed.
diff -ur php-7.1.0RC5.orig/ext/openssl/openssl.c php-7.1.0RC5/ext/openssl/openssl.c
--- php-7.1.0RC5.orig/ext/openssl/openssl.c	2016-10-25 08:23:21.0 -0700
+++ php-7.1.0RC5/ext/openssl/openssl.c	2016-10-29 17:02:33.549137954 -0700
@@ -669,7 +669,7 @@
 	return 1;
 }
 
-#if OPENSSL_VERSION_NUMBER < 0x10002000L
+#if OPENSSL_VERSION_NUMBER < 0x10002000L || defined (LIBRESSL_VERSION_NUMBER)
 
 static int X509_get_signature_nid(const X509 *x)
 {

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