Req #62372 [Com]: crypt() and broken backwards compability in SHA rounds
Edit report at https://bugs.php.net/bug.php?id=62372edit=1
ID: 62372
Comment by: m dot staab at complex-it dot de
Reported by:jani dot ollikainen at mmd dot net
Summary:crypt() and broken backwards compability in SHA
rounds
Status: Open
Type: Feature/Change Request
Package:*Encryption and hash functions
PHP Version:5.4.4
Block user comment: N
Private report: N
New Comment:
I have the very same issues. Updating from PHP5.2.4 to PHP5.4.11 and now my
passwords which were hased using PHP5.2.4 do not match any longer on PHP5.4.11.
I found no way how to re-produce passwords on PHP5.4.11 like they were
generated on PHP5.2.4 and therefore I have no way to upgrade users which
already have a password to a newly generated with PHP5.4.11..
The only way I can think of is a password-reset for all of our users?!
Previous Comments:
[2012-06-20 20:33:17] jani dot ollikainen at mmd dot net
Oh now I get what I did wrong with PHP 5.1.6. It doesn't understand rounds at
all, it's just looks like it does, but it uses it as salt and new PHP doesn't
allow = in salt, so it doesn't work as they see different salt in it. So the
compatibility issue is with salt string, not in rounds at all.
This can be work around in PHP 5.1.6 not to use salt's which newer versions
don't understand, but if you already use them, then you're in big trouble.
Another one is that if I have password like: http://3v4l.org/amNND
The hash is generated with patched PHP 5.4.4 with ROUNDS_MIN 1, but it could be
from some other system. PHP cannot verify it, as the rounds limit 1000 is
enforced. To me enforcing it seems to limit compability.
[2012-06-20 19:32:11] arjen at react dot com
Looks like PHP = 5.1.7 has a limit on the saltstring of 9 chars.
If no $rounds is specified AND a salstring of 9 chars, all versions return the
same hash: http://3v4l.org/nDiFd (2nd line, 1st line is with long hash).
[2012-06-20 11:44:29] jani dot ollikainen at mmd dot net
Tested with patched 5.4.4 where:
#define ROUNDS_MIN 1
HASH:
$6$rounds=10$qNElXs2yMnL2.GNS3kiM7DqmGbFLdQfIwu2691aJgT3xgJazPLtw7RPKz3Dp8RIc4b5fmJ7qvlq/mPN8a.rE40
- CRYPT:
$6$rounds=10$qNElXs2yMnL2.GNS$YwaYQmhwsN2RzBImxlEjIL.0/YLlfYCDmyfozkCQWNKdKgZQtTpK3Y/TAw31deCnJrDzgrqpI6ckvJCBsoeNB/
NO MATCH
So problem isn't only in ROUNDS_MIN. Also I know that my hash hasn't $ after
salt, but that's how PHP 5.1.6 creates it. Tested also with adding $ and result
is similar:
HASH:
$6$rounds=10$qNElXs2yMnL2.GNS$3kiM7DqmGbFLdQfIwu2691aJgT3xgJazPLtw7RPKz3Dp8RIc4b5fmJ7qvlq/mPN8a.rE40
- CRYPT:
$6$rounds=10$qNElXs2yMnL2.GNS$YwaYQmhwsN2RzBImxlEjIL.0/YLlfYCDmyfozkCQWNKdKgZQtTpK3Y/TAw31deCnJrDzgrqpI6ckvJCBsoeNB/
NO MATCH
So something else is also different...
[2012-06-20 10:58:38] jani dot ollikainen at mmd dot net
Description:
http://fi2.php.net/manual/en/function.crypt.php
CRYPT_SHA512 - SHA-512 hash with a sixteen character salt prefixed with $6$.
If the salt string starts with 'rounds=N$', the numeric value of N is used to
indicate how many times the hashing loop should be executed, much like the cost
parameter on Blowfish. The default number of rounds is 5000, there is a minimum
of 1000 and a maximum of 999,999,999. Any selection of N outside this range
will be truncated to the nearest limit.
Why is that N put to minium of 1000? Now if I've made hash with old PHP (or
with anything else) which has $6$rounds=10$ I cannot check that, because if
there's rounds mentioned PHP will do minimum of 1000 rounds and I get totally
different hash to compare.
Sounds very nice! I can understant that rounds limit if I don't give salt to
crypt(), but if I give a salt which has $6$rounds=10$ it really should do
just those 10 rounds!
Fails with:
PHP 5.4.4 (cli) (built: Jun 20 2012 13:48:48)
PHP 5.3.14 (cli) (built: Jun 20 2012 13:39:44)
PHP 5.3.3 (cli) (built: May 7 2012 19:58:17)
Works with:
PHP 5.1.6 (cli) (built: May 7 2012 15:03:06)
Test script:
---
?php
$h='$6$rounds=10$qNElXs2yMnL2.GNS3kiM7DqmGbFLdQfIwu2691aJgT3xgJazPLtw7RPKz3Dp8RIc4b5fmJ7qvlq/mPN8a.rE40';
$p='salasana';
$c=crypt($p,$h);
echo HASH: $h - CRYPT: $c\n;
if ($c == $h)
{
echo MATCH OK\n;
}
else
{
echo NO MATCH\n;
}
?
Expected result:
HASH:
$6$rounds=10$qNElXs2yMnL2.GNS3kiM7DqmGbFLdQfIwu2691aJgT3xgJazPLtw7RPKz3Dp8RIc4b5fmJ7qvlq/mPN8a.rE40
- CRYPT:
$6$rounds=10$qNElXs2yMnL2.GNS3kiM7DqmGbFLdQfIwu2691aJgT3xgJazPLtw7RPKz3Dp8RIc4b5fmJ7qvlq/mPN8a.rE40
MATCH OK
Actual result:
--
HASH:
[PHP-BUG] Bug #64302 [NEW]: Memory leak in ext/phar/tests/bug52013.phpt
From: ab Operating system: all PHP version: 5.5Git-2013-02-26 (Git) Package: PHAR related Bug Type: Bug Bug description:Memory leak in ext/phar/tests/bug52013.phpt Description: Running the mentioned test with valgrind is to see Expected result: no valgrind warnings Actual result: -- ==22761== Syscall param write(buf) points to uninitialised byte(s) ==22761==at 0x5924EB3: __write_nocancel (syscall-template.S:82) ==22761==by 0x85852E8: _php_stream_filter_flush (filter.c:504) ==22761==by 0x831BE2F: phar_flush (phar.c:2903) ==22761==by 0x832B1DE: zim_Phar_compressFiles (phar_object.c:3436) ==22761==by 0x863FFA4: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:542) ==22761==by 0x8641374: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:674) ==22761==by 0x863E004: execute_ex (zend_vm_execute.h:356) ==22761==by 0x863E9BA: zend_execute (zend_vm_execute.h:381) ==22761==by 0x85FF017: zend_execute_scripts (zend.c:1316) ==22761==by 0x85615FB: php_execute_script (main.c:2479) ==22761==by 0x875C33C: do_cli (php_cli.c:988) ==22761==by 0x875D785: main (php_cli.c:1364) ==22761== Address 0x6187d1b is 11 bytes inside a block of size 15 alloc'd ==22761==at 0x4024F20: malloc (vg_replace_malloc.c:236) ==22761==by 0x85C3E62: _emalloc (zend_alloc.c:2427) ==22761==by 0x85C4356: _estrndup (zend_alloc.c:2641) ==22761==by 0x81C613C: php_zlib_deflate_filter (zlib_filter.c:250) ==22761==by 0x8585094: _php_stream_filter_flush (filter.c:452) ==22761==by 0x831BE2F: phar_flush (phar.c:2903) ==22761==by 0x832B1DE: zim_Phar_compressFiles (phar_object.c:3436) ==22761==by 0x863FFA4: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:542) ==22761==by 0x8641374: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:674) ==22761==by 0x863E004: execute_ex (zend_vm_execute.h:356) ==22761==by 0x863E9BA: zend_execute (zend_vm_execute.h:381) ==22761==by 0x85FF017: zend_execute_scripts (zend.c:1316) ==22761== -- Edit bug report at https://bugs.php.net/bug.php?id=64302edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64302r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64302r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64302r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64302r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64302r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64302r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64302r=needscript Try newer version: https://bugs.php.net/fix.php?id=64302r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64302r=support Expected behavior: https://bugs.php.net/fix.php?id=64302r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64302r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64302r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64302r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64302r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64302r=dst IIS Stability: https://bugs.php.net/fix.php?id=64302r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64302r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64302r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64302r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64302r=mysqlcfg
Bug #64070 [Com]: Inheritance with Traits failed with error
Edit report at https://bugs.php.net/bug.php?id=64070edit=1 ID: 64070 Comment by: alexander at mailinator dot net Reported by:denny dot reeh at gmail dot com Summary:Inheritance with Traits failed with error Status: Closed Type: Bug Package:Scripting Engine problem PHP Version:5.4.11 Assigned To:dmitry Block user comment: N Private report: N New Comment: Patch do not included in php 5.4.12. But in php 5.4.13 branch bug fixed: PHP 5.4.13-dev (cgi-fcgi) (built: Feb 24 2013 07:42:48) Previous Comments: [2013-02-22 08:28:51] dmi...@php.net The bug is definitely fixed, However I'm not sure if it's included into 5.4.12 release or not. $ sapi/cli/php bug64070.php From Second Trait From First Trait $ sapi/cli/php -v PHP 5.4.13-dev (cli) (built: Feb 21 2013 16:29:23) [2013-02-21 22:16:00] alexander at mailinator dot net Problem has not solved yet. Test snapshot http://windows.php.net/downloads/snaps/php-5.4/r86c1a26/ and bug still present in it. [2013-02-18 12:37:45] dmi...@php.net The fix for this bug has been committed. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. [2013-02-18 12:36:39] dmi...@php.net Automatic comment on behalf of dmi...@zend.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=42437dd870de28eee6c9127f4c7e7c78ba8e0152 Log: Fixed bug #64070 (Inheritance with Traits failed with error) [2013-02-18 10:41:18] inefedor at gmail dot com Hi, I checked this problem with the master branch and yes, I was wrong, here's PR I attached to this bug, it solves the problem, but it won't work with xdebug extension. I'm not familiar with code of xdebug, I will contact with Derick about it. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=64070 -- Edit this bug report at https://bugs.php.net/bug.php?id=64070edit=1
Bug #64302 [Opn]: Invalid read in ext/phar/tests/bug52013.phpt
Edit report at https://bugs.php.net/bug.php?id=64302edit=1 ID: 64302 Updated by: larue...@php.net Reported by:a...@php.net Summary:Invalid read in ext/phar/tests/bug52013.phpt Status: Open Type: Bug Package:PHAR related Operating System: all PHP Version:5.5Git-2013-02-26 (Git) Block user comment: N Private report: N New Comment: same in 5.3 Previous Comments: [2013-02-26 10:24:21] a...@php.net Description: Running the mentioned test with valgrind is to see Expected result: no valgrind warnings Actual result: -- ==22761== Syscall param write(buf) points to uninitialised byte(s) ==22761==at 0x5924EB3: __write_nocancel (syscall-template.S:82) ==22761==by 0x85852E8: _php_stream_filter_flush (filter.c:504) ==22761==by 0x831BE2F: phar_flush (phar.c:2903) ==22761==by 0x832B1DE: zim_Phar_compressFiles (phar_object.c:3436) ==22761==by 0x863FFA4: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:542) ==22761==by 0x8641374: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:674) ==22761==by 0x863E004: execute_ex (zend_vm_execute.h:356) ==22761==by 0x863E9BA: zend_execute (zend_vm_execute.h:381) ==22761==by 0x85FF017: zend_execute_scripts (zend.c:1316) ==22761==by 0x85615FB: php_execute_script (main.c:2479) ==22761==by 0x875C33C: do_cli (php_cli.c:988) ==22761==by 0x875D785: main (php_cli.c:1364) ==22761== Address 0x6187d1b is 11 bytes inside a block of size 15 alloc'd ==22761==at 0x4024F20: malloc (vg_replace_malloc.c:236) ==22761==by 0x85C3E62: _emalloc (zend_alloc.c:2427) ==22761==by 0x85C4356: _estrndup (zend_alloc.c:2641) ==22761==by 0x81C613C: php_zlib_deflate_filter (zlib_filter.c:250) ==22761==by 0x8585094: _php_stream_filter_flush (filter.c:452) ==22761==by 0x831BE2F: phar_flush (phar.c:2903) ==22761==by 0x832B1DE: zim_Phar_compressFiles (phar_object.c:3436) ==22761==by 0x863FFA4: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:542) ==22761==by 0x8641374: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:674) ==22761==by 0x863E004: execute_ex (zend_vm_execute.h:356) ==22761==by 0x863E9BA: zend_execute (zend_vm_execute.h:381) ==22761==by 0x85FF017: zend_execute_scripts (zend.c:1316) ==22761== -- Edit this bug report at https://bugs.php.net/bug.php?id=64302edit=1
Bug #53035 [Com]: finfo_file() returns incorrect mimetype
Edit report at https://bugs.php.net/bug.php?id=53035edit=1
ID: 53035
Comment by: stepan dot stepanov at gmail dot com
Reported by:stuart at horuskol dot net
Summary:finfo_file() returns incorrect mimetype
Status: Feedback
Type: Bug
Package:Filesystem function related
Operating System: Linux/Ubuntu 10.04
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
PHP fileinfo library = 1.0.5-dev
Previous Comments:
[2013-02-25 18:37:09] paj...@php.net
no, I meant the file/fileinfo library on your system. file and php does not
share the same version.
[2013-02-25 15:57:31] stepan dot stepanov at gmail dot com
Do you mean version of PHP ?
PHP 5.3.19 (cli)
[2013-02-25 15:55:23] paj...@php.net
Which version do you use on this system?
We may need to update the bundled database or library.
[2013-02-25 14:59:42] stepan dot stepanov at gmail dot com
Command line file programm shows the right result. Though php reports wrong
one.
CentOS release 5.8
See details below:
$ file -i char2.csv
char2.csv: text/plain; charset=us-ascii
$ file -i char.csv
char.csv: text/plain; charset=us-ascii
$ php -f mimetest.php
char2.csv: text/plain
char.cvs: text/x-c
$ diff -u char2.csv char.csv
--- char2.csv 2012-10-10 15:07:05.0 +0200
+++ char.csv2013-02-25 15:47:38.0 +0100
@@ -1,3 +1,4 @@
stepan.stepa...@somewhere.com
stepan.stepa...@somewhereelse.com
+charlo...@server.com
herr.totalschei...@mime.typ
--
$ php -v
PHP 5.3.19 (cli) (built: Nov 25 2012 13:17:45)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
with Xdebug v2.1.3, Copyright (c) 2002-2012, by Derick Rethans
$ cat mimetest.php
?
$finfo = new finfo(FILEINFO_MIME_TYPE);
echo \nchar2.csv: .$finfo-file('char2.csv');
echo \nchar.cvs: .$finfo-file('char.csv');
?
[2013-02-18 00:34:31] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to Open. Thank you.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=53035
--
Edit this bug report at https://bugs.php.net/bug.php?id=53035edit=1
Req #51254 [Com]: Use internal crypt() only for algorithms needed
Edit report at https://bugs.php.net/bug.php?id=51254edit=1 ID: 51254 Comment by: iamguinness at gmail dot com Reported by:ondrej at sury dot org Summary:Use internal crypt() only for algorithms needed Status: Open Type: Feature/Change Request Package:*Encryption and hash functions Operating System: Linux PHP Version:5.3.2 Block user comment: N Private report: N New Comment: I was wondering if the problem that php at rapsys dot eu reported is going to be fixed. I had the same issue with a custom build on Ubuntu and had to drop this patch. Since it's almost three years old know, I'm just wondering if anyone has bothered to dig deeper into this problem. I'm afraid I don't have the skills to do so... Previous Comments: [2011-03-28 16:37:47] ondrej at sury dot org Hi, the issue is little bit more complicated than adding defined() around the statements. When compiling with --enable-maintainer-zts some header files are included in a way that crypt_r and struct crypt_data is unknown and the compilation fail. Unless you are willing to dig deeper, you can just drop the patch for your custom build. [2011-03-28 15:12:41] php at rapsys dot eu I had a poblem with this patch in debian/ubuntu packages. With this patch the build with --enable-maintainer-zts the ubuntu php5_5.3.2-1ubuntu4.7 package. The problem seems to comes from #if used instead of #ifdef and incorrectly defined strings by your patch. Here is the build log : /home/user/php/php5-5.3.2/ext/standard/crypt.c:150:27: error: #if with no expression /home/user/php/php5-5.3.2/ext/standard/crypt.c:190:27: error: #if with no expression /home/user/php/php5-5.3.2/ext/standard/crypt.c:201:3: warning: #warning Using system MD5 crypt function, which is OK on Debian system /home/user/php/php5-5.3.2/ext/standard/crypt.c:202:28: error: #if with no expression /home/user/php/php5-5.3.2/ext/standard/crypt.c:214:3: warning: #warning Using system SHA512 crypt function, which is OK on Debian system /home/user/php/php5-5.3.2/ext/standard/crypt.c:215:28: error: #if with no expression /home/user/php/php5-5.3.2/ext/standard/crypt.c:227:3: warning: #warning Using system SHA256 crypt function, which is OK on Debian system /home/user/php/php5-5.3.2/ext/standard/crypt.c:228:28: error: #if with no expression /home/user/php/php5-5.3.2/ext/standard/crypt.c:258:3: warning: #warning Using PHP BlowFish crypt function, which is OK on Debian system /home/user/php/php5-5.3.2/ext/standard/crypt.c:272:3: warning: #warning Using PHP extended DES crypt function, which is OK on Debian system /home/user/php/php5-5.3.2/ext/standard/crypt.c:279:3: warning: #warning Using system standard DES crypt function, which is OK on Debian system /home/user/php/php5-5.3.2/ext/standard/crypt.c:280:28: error: #if with no expression make[1]: *** [ext/standard/crypt.lo] Error 1 make[1]: Leaving directory `/home/user/php/php5-5.3.2/apache2-build' make: *** [build-apache2-stamp] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 debuild: fatal error at line 1340: dpkg-buildpackage -rfakeroot -D -us -uc failed [2010-03-24 17:02:06] ondrej at sury dot org Hi Pierre, had a time to review this patch and provide a detailed explanation? Ondrej [2010-03-12 11:24:42] paj...@php.net Not sure I agree with these changes, they are not supposed to be valid. I don't have the time now to reply with a detailed explanation but we will do it asap. [2010-03-12 10:15:46] ondrej at sury dot org Hi, if you apply my patch, you'll need to apply the fix_crypt_unit_tests.patch, since I have fixed some routines, which you checked in those unit tests. 1. if you use '_' as a first character of the salt, but the salt is not 9 characters long = STD_DES is used. 2. if you use 00-03 or 32-39 as count in blowfish = STD_DES is used (as documented). The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=51254 -- Edit this bug report at https://bugs.php.net/bug.php?id=51254edit=1
Req #45543 [Com]: DateTime::setTimezone can not set timezones without ID
Edit report at https://bugs.php.net/bug.php?id=45543edit=1
ID: 45543
Comment by: rrollins at caltech dot edu
Reported by:tj at systisoft dot com
Summary:DateTime::setTimezone can not set timezones without
ID
Status: Assigned
Type: Feature/Change Request
Package:Date/time related
Operating System: All
PHP Version:5.3CVS-2008-07-17 (CVS)
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
I'm getting this warning when trying to set a DateTime's timezone to
America/Los_Angeles. I don't know what an ID is in this context, but surely
America/Los_Angeles has one... right? I'm using PHP 5.3.21 on OSX Mountain Lion.
Previous Comments:
[2013-01-02 20:11:57] info at strictcoding dot co dot uk
Still the same in PHP 5.4.10.
This bug is more than 4 years old, could it be looked into?
[2011-01-08 19:56:01] wrzasq at gmail dot com
I confirm the same on PHP 5.3.3, Debian 64bit.
[2009-06-29 16:25:01] scott at crisscott dot com
I was able to reproduce this with PHP 5.2.9 from the commandline.
php -v
PHP 5.2.9 (cli) (built: May 1 2009 13:47:24)
$ php -r '$d = new DateTime(2009-01-01 00:00:00+0400);
$d-setTimezone($d-getTimezone());'
[2008-07-17 14:34:47] tj at systisoft dot com
Description:
If you set a time zone for a DateTime via DateTime::setTimeZone() and that time
zone has no ID you get an error message and the time zone will not be set.
This can lead to problems if you have two DateTime objects from a source you do
not control and want to format the second DateTime object in the same time zone
as the first.
Reproduce code:
---
$d1 = new DateTime('2008-01-01 12:00:00 +02:00');
$d2 = new DateTime('2008-01-01 12:00:00 UTC');
echo $d1-format(DATE_ISO8601), PHP_EOL;
echo $d2-format(DATE_ISO8601), PHP_EOL;
$d2-setTimeZone($d1-getTimeZone());
echo $d1-format(DATE_ISO8601), PHP_EOL;
echo $d2-format(DATE_ISO8601), PHP_EOL;
Expected result:
2008-01-01T12:00:00+0200
2008-01-01T12:00:00+
2008-01-01T12:00:00+0200
2008-01-01T14:00:00+0200
Actual result:
--
2008-01-01T12:00:00+0200
2008-01-01T12:00:00+
PHP Warning: DateTime::setTimezone(): Can only do this for zones with
ID for now in /Users/tobias/test.php on line 5
Warning: DateTime::setTimezone(): Can only do this for zones with ID for
now in /Users/tobias/test.php on line 5
2008-01-01T12:00:00+0200
2008-01-01T12:00:00+
[2008-07-17 13:07:47] tj at systisoft dot com
Description:
if you set a time zone for a DateTime via DateTime::setTimeZone() and that time
zone has no ID you get an error message and the time zone will not be set.
This can lead to Problems if you have two DateTime objects from a surce you do
not control and want to format the secont DateTime object in the same time zone
as the first.
Reproduce code:
---
$d1 = new DateTime('2008-01-01 12:00:00 +02:00');
$d2 = new DateTime('2008-01-01 12:00:00 UTC');
echo $d1-format(DATE_ISO8601), PHP_EOL;
echo $d2-format(DATE_ISO8601), PHP_EOL;
$d2-setTimeZone($d1-getTimeZone());
echo $d1-format(DATE_ISO8601), PHP_EOL;
echo $d2-format(DATE_ISO8601), PHP_EOL;
Expected result:
2008-01-01T12:00:00+0200
2008-01-01T12:00:00+
2008-01-01T12:00:00+0200
2008-01-01T14:00:00+0200
Actual result:
--
2008-01-01T12:00:00+0200
2008-01-01T12:00:00+
PHP Warning: DateTime::setTimezone(): Can only do this for zones with ID for
now in /Users/tobias/test.php on line 5
Warning: DateTime::setTimezone(): Can only do this for zones with ID for now in
/Users/tobias/test.php on line 5
2008-01-01T12:00:00+0200
2008-01-01T12:00:00+
--
Edit this bug report at https://bugs.php.net/bug.php?id=45543edit=1
Bug #61354 [Com]: htmlentities and htmlspecialchars doesn't respect the default_charset
Edit report at https://bugs.php.net/bug.php?id=61354edit=1 ID: 61354 Comment by: rudibr at gmail dot com Reported by:hufeng1987 at gmail dot com Summary:htmlentities and htmlspecialchars doesn't respect the default_charset Status: Not a bug Type: Bug Package:Strings related Operating System: Linux/Windows/ PHP Version:5.4.0 Block user comment: N Private report: N New Comment: What about my third-party modules? Should I change their code as well? Do I now need to verify and manually alter code on third-party modules everytime I upgrade or install them? If Im using a component with protected code, do I need to go trough their support staff and wait for a correction? What if they provide no reliable support or customization, am I now being encouraged to hack and crack in the source code just so I can fix this? It is easy , even redundant , and absolutely justfiable to create a new ini setting to control this behavior, that I feel a little bit offended by the current attitude of php developers over this issue. I also feel a little bit offended because the guy who is responsible for this change EXPLICITLY stated that the change to UTF-8 defaulting have nothing to do with security. It just sounded like a better default, according to the developer. Hardly a seriously thought-trough consideration. This is becoming quite a sad state of affairs. I guess I will have to consider moving on from php if it comes to that. Previous Comments: [2013-01-27 17:32:18] kstirn at gmail dot com It will soon be a year since the release of PHP 5.4 and there still is no easy way (read: a global PHP setting) to overcome this huge backwards-incompatibility. PHP developers, I understand the security concerns, but please don't be so stubborn and give us an option to set a default setting without having to modify *all* legacy code to work with 5.4. Your action (or lack thereof) is producing the opposite results of desired - instead of moving to PHP 5.4, thousands of servers (including several we own) will stay with 5.3.x even after end of life cycle in March 2013. *Fact* A simple global setting (an optional php.ini value) would solve the issue for thousands of users while addressing security issues by explicitly defining the default charset to be used by affected functions - all without having to rewrite existing code. PHP team please do reconsider this and help everyone not using UTF-8 move to PHP 5.4. Thank you! [2013-01-05 17:39:04] x dot bazilio at gmail dot com Ok. If i did not set defautlt time zone, i get E_WARNING. Let us set default encoding for htmlspecialchars. It is not posible to persuade developers of Drupal, joomla, wordpress, bitrix, ets., and developers of modules for that CMS to rewrite their code. I wrote to tech support of bitrix (russian cms). They said that i must use PHP 5.3.x. They not going to rewrite code. [2013-01-05 16:05:31] leaflet at leafok dot com I understand your consideration. Maybe a global configuration in PHP.ini or page lifecycle set function could be provided for encoding setting of these functions. Developers would be glad to handle this setting centrally by a include header file for each pages. [2013-01-05 15:17:56] ras...@php.net I have explained that a few times. We can't default it automatically because the encoding may not match the output encoding. Only the developer knows that. If we did that automatically it would break even more sites. The sites where the encodings differ need to set it explicitly. [2013-01-05 09:54:44] hufeng1987 at gmail dot com pass null and empty string that could improve security? no sense.. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=61354 -- Edit this bug report at https://bugs.php.net/bug.php?id=61354edit=1
Bug #64294 [Com]: date conversion problem when dst present
Edit report at https://bugs.php.net/bug.php?id=64294edit=1
ID: 64294
Comment by: mail+php at requinix dot net
Reported by:ybrigant at gmail dot com
Summary:date conversion problem when dst present
Status: Open
Type: Bug
Package:Date/time related
Operating System: linux debian
PHP Version:5.3.22
Block user comment: N
Private report: N
New Comment:
DST in Europe ends at 2013-10-27 01:00.
By the way, Unix timestamps don't have timezones.
Previous Comments:
[2013-02-25 10:42:18] ybrigant at gmail dot com
Sorry, I forgot to add that timestamp provided is in utc timezone.
[2013-02-25 09:55:35] ybrigant at gmail dot com
Description:
COnversion of an utc timestamp to a date in a scpecific timezone, ie
EUrope/Paris where we have dst activated in the date example...
Test script:
---
$timestamp = 1382954400;
$date = new \DateTime('@'.$timestamp);
$tz = new \DateTimeZone('Europe/Paris');
$date-setTimezone($tz);
return $date-format(Y-m-d H:i');
Expected result:
2013-10-28 12:00
Actual result:
--
2013-10-28 11:00
--
Edit this bug report at https://bugs.php.net/bug.php?id=64294edit=1
Bug #64294 [Com]: date conversion problem when dst present
Edit report at https://bugs.php.net/bug.php?id=64294edit=1
ID: 64294
Comment by: mail+php at requinix dot net
Reported by:ybrigant at gmail dot com
Summary:date conversion problem when dst present
Status: Open
Type: Bug
Package:Date/time related
Operating System: linux debian
PHP Version:5.3.22
Block user comment: N
Private report: N
New Comment:
01:00 UTC that is, so 02:00 Europe/Paris.
Previous Comments:
[2013-02-27 01:26:11] mail+php at requinix dot net
DST in Europe ends at 2013-10-27 01:00.
By the way, Unix timestamps don't have timezones.
[2013-02-25 10:42:18] ybrigant at gmail dot com
Sorry, I forgot to add that timestamp provided is in utc timezone.
[2013-02-25 09:55:35] ybrigant at gmail dot com
Description:
COnversion of an utc timestamp to a date in a scpecific timezone, ie
EUrope/Paris where we have dst activated in the date example...
Test script:
---
$timestamp = 1382954400;
$date = new \DateTime('@'.$timestamp);
$tz = new \DateTimeZone('Europe/Paris');
$date-setTimezone($tz);
return $date-format(Y-m-d H:i');
Expected result:
2013-10-28 12:00
Actual result:
--
2013-10-28 11:00
--
Edit this bug report at https://bugs.php.net/bug.php?id=64294edit=1
Bug #64258 [Com]: XMLReader not compatibile with new libxml2 (undefined symbol: xmlTextReaderSet)
Edit report at https://bugs.php.net/bug.php?id=64258edit=1 ID: 64258 Comment by: veillard at redhat dot com Reported by:spamik at yum dot pl Summary:XMLReader not compatibile with new libxml2 (undefined symbol: xmlTextReaderSet) Status: Open Type: Bug Package:XML Reader PHP Version:5.4.11 Block user comment: N Private report: N New Comment: just to point out that xmlTextReaderSetup is not part of libxml2 ABI, nor on current version nor on 2.6.26. thinkpad:~/XML - grep xmlTextReaderSetup doc/libxml2-api.xml thinkpad:~/XML - [root@test-rhel55 ~]# gunzip -c /usr/share/doc/libxml2-devel-2.6.26/libxml2-api.xml.gz | grep xmlTextReaderSetup [root@test-rhel55 ~]# it would be good if PHP didn't use name which looks like that they are coming from libxml2 even if they are possibly wrappers around libxml2 functions. Previous Comments: [2013-02-22 01:56:19] spamik at yum dot pl I would guess that mere presence of --with-mcrypt on configure breaks linking to custom libxml2 directory (--with-libxml-dir=/usr/libxml2-2.9.0/) and it defaults to system /usr/lib64 (and there is distro standard old libxml2 there which break things). [2013-02-22 01:38:34] spamik at yum dot pl also during make install (php) i see ./configure '--prefix' '/usr/share/php-5.3.21' --with-libxml-dir=/usr/libxml2- 2.9.0/ '--with-mcrypt make install /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) I did not linked to usr/lib64/libxml2.so.2 !! Some error in linking (but only when mcrypt is present) [2013-02-22 01:23:02] spamik at yum dot pl Problem appears when compiling with mcrypt and extension (and libxml2 2.9) Package libmcrypt-devel-2.5.8-4.el5.centos.x86_64 already installed and latest version ./configure '--prefix' '/usr/share/php-5.3.21' --with-libxml-dir=/usr/libxml2- 2.9.0/ '--with-mcrypt make install ?php $xml = new XMLReader(); $xmldata = 'TestOnetagdata/tagtagdata/tag/TestOne'; $xml-XML($xmldata); ? /usr/bin/php: symbol lookup error: /usr/bin/php: undefined symbol: xmlTextReaderSetup I've also tried compiling libmcrypt from source - no changes. ./configure --prefix=/usr/libmcrypt-2.5.8 --disable-posix-threads make install ./configure '--prefix' '/usr/share/php-5.3.21' --with-libxml-dir=/usr/libxml2- 2.9.0/
Bug #52861 [Opn-Csd]: unset failes with ArrayObject and deep arrays
Edit report at https://bugs.php.net/bug.php?id=52861edit=1
ID: 52861
Updated by: s...@php.net
Reported by:mep_eisen at web dot de
Summary:unset failes with ArrayObject and deep arrays
-Status: Open
+Status: Closed
Type: Bug
Package:SPL related
Operating System: Windows Vista 64
PHP Version:5.3.3
-Assigned To:
+Assigned To:stas
Block user comment: N
Private report: N
New Comment:
The fix for this bug has been committed.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
merged as 61099f85857193c223dd62b0c5302507a77cf0ab
Previous Comments:
[2011-11-18 13:49:14] nemo at ikkoku dot de
One can still use unset if one writes:
--- 8 ---
$a = ArrayObject(Array('foo' = Array('bar' = 1)));
// Won't work ($a['foo']['bar'] is still 1)
// Also a notice is displayed: PHP Notice: Indirect modification of
// overloaded element of ArrayObject has no effect in php shell code on line ...
var_dump($a);
unset($a['foo']['bar']);
var_dump($a);
// This works
var_dump($a);
$v = $a['foo'];
unset($v['bar']);
var_dump($a);
// This also works
//$v = $a['foo']['bar'];
//unset($v);
--- 8 ---
[2011-01-07 12:37:52] auke at muze dot nl
Just checked with php 5.3.3 and there the code runs as expected, so at least
setting works with a nested array.
For the record I tried the original bugreport code as well and got the same
result, on a linux system, 64 bits (debian), but also this notice:
PHP Notice: Indirect modification of overloaded element of ArrayObject has no
effect in /var/www/test/test.php on line 22
So at least PHP is honest in that it doesn't work :)
[2011-01-07 12:07:34] auke at muze dot nl
I found a workaround for the problem that suddenly the parent object has any
property you try to access and has it filled with the previously set array.
If the containing object has its own __get() method which always returns NULL,
the object is safe again. So this code works as expected:
class IWouldLikeToPointOutABug {
function __get( $name ) {
return NULL;
}
}
$buggy = new IWouldLikeToPointOutABug();
$buggy-bug = new ArrayObject( );
$buggy-bug['foo']['bar'] = true;
echo This looks normal\r\n;
var_dump( $buggy );
echo This should be NULL\r\n;
var_dump( $buggy-thisIsNotHere );
One drawback is that you cannot assign properties by reference anymore because
you're now using the __get() overloading method.
This does not fix the original bug where unsetting fails.
BTW. Our original workaround involved creating our own arrayobject by
implementing all the array interfaces, but that will not work either. When you
do this:
$arrayobject['unsetkey']['key'] = $value;
The offsetSet method is never called for 'unsetKey', just the offsetGet. So
there is no way to implement the correct behaviour.
[2011-01-05 18:51:51] auke at muze dot nl
It's worse than this, ArrayObject gets confused on where to put the data and
mangles any containing object:
test script:
class IWouldLikeToPointOutABug {
}
$buggy = new IWouldLikeToPointOutABug();
$buggy-bug = new ArrayObject( );
$buggy-bug['foo']['bar'] = true;
echo This looks normal\r\n;
var_dump( $buggy );
echo This should be NULL\r\n;
var_dump( $buggy-thisIsNotHere );
Results in:
This looks normal
object(IWouldLikeToPointOutABug)#1 (1) {
[bug]=
object(ArrayObject)#2 (0) {
}
}
This should be NULL
array(1) {
[bar]=
bool(true)
}
[2010-09-16 17:23:11] mep_eisen at web dot de
Description:
Using deep arrays unset itself or ArrayObject misbehaves. It silently does
nothing.
The problem lies in iteration 3 that mixes ArrayObject and classic arrays.
Test script:
---
echo iteration1\n;
$arr = new ArrayObject();
$arr['foo'] = new ArrayObject();
$arr['foo']['bar'] = true;
unset($arr['foo']['bar']);
var_dump($arr);
echo iteration2\n;
$arr = array();
$arr['foo']['bar'] = true;
unset($arr['foo']['bar']);
var_dump($arr);
echo iteration3\n;
$arr = new ArrayObject();
$arr['foo']['bar'] = true;
unset($arr['foo']['bar']);
var_dump($arr);
Expected result:
iteration1
