[PHP-BUG] Bug #60596 [NEW]: Code Cleanup Removing Superfluous If Statement
From: ircmaxell Operating system: Any PHP version: trunk-SVN-2011-12-22 (SVN) Package: SPL related Bug Type: Bug Bug description:Code Cleanup Removing Superfluous If Statement Description: The switch statement for spl_offset_convert_to_long has a superfluous IF statement that is unnecessary (and causes an unnecessary Z_TYPE_P macro expansion). I've attached a patch which refactors this to remove the if statement. I wasn't sure to classify this as a bug or not since it doesn't affect PHP at all, but it's just code-cleanup. Anthony -- Edit bug report at https://bugs.php.net/bug.php?id=60596&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60596&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60596&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60596&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60596&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60596&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60596&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60596&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60596&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60596&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60596&r=support Expected behavior: https://bugs.php.net/fix.php?id=60596&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60596&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60596&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60596&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60596&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60596&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60596&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60596&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60596&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60596&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60596&r=mysqlcfg
[PHP-BUG] Req #60813 [NEW]: Implement PBKDF2 function in hash
From: ircmaxell Operating system: All PHP version: trunk-SVN-2012-01-19 (snap) Package: hash related Bug Type: Feature/Change Request Bug description:Implement PBKDF2 function in hash Description: I propose to implment a PBKDF2 derivation function in the hash package as hash_pbkdf2(). PBKDF2 is defined in PKCS#5 (RFC 2898). The method for password hash derivation is currently used by Blackberry, Apple iOS, Microsoft, OpenOffice, and more (not all for password storage, but all for password based hashing). The patch also cleans up hash_hmac a little bit to split out some common functionality into a few inline functions (since PBKDF2 relies heavily on hmac). Test script: --- https://bugs.php.net/bug.php?id=60813&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60813&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60813&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60813&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60813&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60813&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60813&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60813&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60813&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60813&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60813&r=support Expected behavior: https://bugs.php.net/fix.php?id=60813&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60813&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60813&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60813&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60813&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60813&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60813&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60813&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60813&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60813&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60813&r=mysqlcfg
Bug #61098 [Com]: crypt() hangs when using Blowfish salt with SHA512 hash
Edit report at https://bugs.php.net/bug.php?id=61098&edit=1
ID: 61098
Comment by: ircmax...@php.net
Reported by:naryndel at hotmail dot com
Summary:crypt() hangs when using Blowfish salt with SHA512
hash
Status: Analyzed
Type: Bug
Package:*Encryption and hash functions
Operating System: RedHat Linux
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
Also, note that the hash methods returned by `hash_algos()` is a different list
than those available via `crypt()` (they are different systems entirely)...
Previous Comments:
[2012-02-15 21:16:28] ras...@php.net
I guess technically this isn't actually a bug. You are asking for a work factor
of
31. Work factors are exponential and 31 is going to take a very very long time.
You could perhaps make a persuasive argument for not allowing work factors that
high.
[2012-02-15 20:32:53] ras...@php.net
Confirmed, this gets stuck in standard/crypt_blowfish.c because of this:
691 count = (BF_word)1 << ((setting[4] - '0') * 10 + (setting[5] -
'0'));
(gdb) p count
$1 = 2147483648
(gdb) p setting[4]
$2 = 51 '3'
(gdb) p setting[5]
$3 = 49 '1'
(gdb) p ((setting[4] - '0') * 10 + (setting[5] - '0'))
$4 = 31
And then there is a while(--count) loop further on that is thus going to take a
long time to complete.
[2012-02-15 20:06:01] naryndel at hotmail dot com
Description:
My hosting company recently upgraded from PHP 5.2.x to PHP 5.3.1.
Using crypt() with a salt following the CRYPT_BLOWFISH format (as shown on
http://ca.php.net/manual/en/function.crypt.php) the script will hang and
timeout
.
Previous to the upgrade the function would process successfully without warning
or error. A call to hash_algos() does list "Blowfish" as a registered hashing
algorithm.
On the documentation page for crypt(), the following note is stated: "As of PHP
5.3.0, PHP contains its own implementation and will use that if the system
lacks
of support for one or more of the algorithms."
So rather than hanging PHP is expected to use an internal algorithm in place
where Blowfish is apparently not supported on the server.
This was further tested by using a sha512-formatted salt for the 2nd argument
(sha512 is listed in the result provided by hash_algos()), which processes
successfully. Also by calling crypt() using the Blowfish salt and attempting
with the 1st argument processed using the hash() function and without - both
instances cause the script to hang as well.
Test script:
---
crypt(hash("sha512","something"),'$2a$31$developer./.excellence$');
Expected result:
The expected result would be an encrypted string using an internal PHP
algorithm
as described within the PHP documentation for the crypt() function.
Actual result:
--
The actual result is that the script will hang until the maximum process time
on
the server is exceeded and the script times out, giving the following error
message:
[warn] mod_fcgid: stderr: PHP Fatal error: Maximum execution time of 30 seconds
exceeded in [script path] on line 30
--
Edit this bug report at https://bugs.php.net/bug.php?id=61098&edit=1
Req #60813 [Com]: Implement PBKDF2 function in hash
Edit report at https://bugs.php.net/bug.php?id=60813&edit=1 ID: 60813 Comment by: ircmax...@php.net Reported by:ircmax...@php.net Summary:Implement PBKDF2 function in hash Status: Open Type: Feature/Change Request Package:hash related Operating System: All PHP Version:trunk-SVN-2012-01-19 (snap) Block user comment: N Private report: N New Comment: This has been submitted as a pull request. RFC to follow: https://github.com/php/php-src/pull/105 Previous Comments: [2012-01-19 22:00:52] ircmax...@php.net Description: I propose to implment a PBKDF2 derivation function in the hash package as hash_pbkdf2(). PBKDF2 is defined in PKCS#5 (RFC 2898). The method for password hash derivation is currently used by Blackberry, Apple iOS, Microsoft, OpenOffice, and more (not all for password storage, but all for password based hashing). The patch also cleans up hash_hmac a little bit to split out some common functionality into a few inline functions (since PBKDF2 relies heavily on hmac). Test script: --- https://bugs.php.net/bug.php?id=60813&edit=1
Req #54638 [Com]: PDO_MYSQL Always Uses Emulated Prepared Statements
Edit report at https://bugs.php.net/bug.php?id=54638&edit=1 ID: 54638 Comment by: ircmax...@php.net Reported by:me at ircmaxell dot com Summary:PDO_MYSQL Always Uses Emulated Prepared Statements Status: Open Type: Feature/Change Request Package:PDO related Operating System: All PHP Version:5.4 Block user comment: N Private report: N New Comment: I've added a pull request for this issue: https://github.com/php/php-src/pull/108 Previous Comments: [2012-05-21 15:26:25] jpa...@php.net I agree we should at least document that behavior. #61969 is related. [2011-04-30 20:38:59] ras...@php.net This is a 5.4 feature request. There were very good reasons for not using the native prepared statement support in MySQL < 5.1.17. [2011-04-30 17:38:08] damien at tournoud dot net Before MySQL 5.1.17, prepared statements completely skip the query cache (see http://dev.mysql.com/doc/refman/5.1/en/query-cache-operation.html). I think it's too early to make the switch. [2011-04-30 02:25:24] me at ircmaxell dot com Description: The PDO_MySQL driver defaults emulate_prepare to 1, which forces all prepared queries to be emulated by the driver. This means that even though the client library (mysqlnd or libmysql) may support prepared statements, PDO will never really use them. You can set the attribute PDO::ATTR_EMULATE_PREPARES to 0, and it prepares and executes the prepared statements just fine using the native mode (rather than emulation). However this is not documented at all on PHP.NET. Since PDO_MYSQL will fallback to emulation automatically if the client library or server are too old for prepared statements, I would suggest that the default value for emulate_prepare should be set to 0 to allow for true prepared statements. -- Edit this bug report at https://bugs.php.net/bug.php?id=54638&edit=1
[PHP-BUG] Bug #62443 [NEW]: Crypt SHA256/512 Segfaults With Malformed Salt
From: ircmaxell Operating system: All PHP version: master-Git-2012-06-28 (Git) Package: Reproducible crash Bug Type: Bug Bug description:Crypt SHA256/512 Segfaults With Malformed Salt Description: Crypt() SHA256 and SHA512 segfault when passed a salt that contains a null byte. This is because the emalloc call and the memset call use different length inputs for the `output` string. The memset call then overflows the buffer. Test script: --- and Expected result: No output Actual result: -- Either segmentation fault (sha512) or zend_mm_heap corrupted (sha256) -- Edit bug report at https://bugs.php.net/bug.php?id=62443&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62443&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62443&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62443&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62443&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62443&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62443&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62443&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62443&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62443&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62443&r=support Expected behavior: https://bugs.php.net/fix.php?id=62443&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62443&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62443&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62443&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62443&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62443&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62443&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62443&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62443&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62443&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62443&r=mysqlcfg
[PHP-BUG] Bug #63363 [NEW]: Curl silently accepts boolean true for SSL_VERIFYHOST
From: ircmaxell Operating system: All PHP version: Irrelevant Package: *Network Functions Bug Type: Bug Bug description:Curl silently accepts boolean true for SSL_VERIFYHOST Description: The CURL option SSL_VERIFYHOST accepts a long value to indicate the verification that should be applied. The following values are valid: 0 - No verification 1 - Check a host is present in cert 2 - Check cert's host matches request's host The problem is that a boolean true is cast to a long 1. Therefore, code that does the following: curl_setopt($c, CURLOPT_SSL_VERIFYHOST, true) appears to be verifying the host. However, it's actually not. This can create security issues that are very hard to find by reading code. Test script: --- https://bugs.php.net/bug.php?id=63363&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63363&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63363&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63363&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63363&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63363&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63363&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63363&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63363&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63363&r=support Expected behavior: https://bugs.php.net/fix.php?id=63363&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63363&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63363&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63363&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63363&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63363&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63363&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63363&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63363&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63363&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63363&r=mysqlcfg
