Bug #63389 [Opn->Csd]: Missing context check on libxml_set_streams_context() causes memleak
Edit report at https://bugs.php.net/bug.php?id=63389&edit=1 ID: 63389 Updated by: larue...@php.net Reported by:fel...@php.net Summary:Missing context check on libxml_set_streams_context() causes memleak -Status: Open +Status: Closed Type: Bug Package:XML related PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=2f1c4064f8fd971166df3099729e74e0ecb5d6bc Log: Fixed bug #63389 (Missing context check on libxml_set_streams_context() causes memleak) Previous Comments: [2012-10-29 21:32:28] fel...@php.net Description: See below. Test script: --- https://bugs.php.net/bug.php?id=63389&edit=1
[PHP-BUG] Bug #63392 [NEW]: DateTime::modify() start of week inconsistency
From: chris at cmbuckley dot co dot uk
Operating system:
PHP version: 5.4Git-2012-10-30 (snap)
Package: Date/time related
Bug Type: Bug
Bug description:DateTime::modify() start of week inconsistency
Description:
Calling $dt->modify("Monday this week") for all dates 13â19 May 2012
(SunâSat)
result in the same date (2012-05-14), suggesting that "this week" runs
SunâSat.
However, calling $dt->modify("Sunday this week") gives the "next" Sunday
(2012-
05-20) for the same range.
On a related note, the documentation on relative date formats is lacking on
the
behaviour of this and strtotime when used with locales; one might expect
the
start of the week to be interpreted from LC_TIME.
Test script:
---
modify("Sunday this week");
var_dump($dt->format('r'));
Expected result:
string(31) "Sun, 13 May 2012 00:00:00 +"
Actual result:
--
string(31) "Sun, 20 May 2012 00:00:00 +"
--
Edit bug report at https://bugs.php.net/bug.php?id=63392&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63392&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63392&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63392&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63392&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63392&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63392&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63392&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63392&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63392&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63392&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63392&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63392&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63392&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63392&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63392&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63392&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63392&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63392&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63392&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63392&r=mysqlcfg
[PHP-BUG] Bug #63391 [NEW]: [PATCH] Incorrect/inconsistent day of week prior to the year 1600
From: tcarter at noggin dot com dot au Operating system: Linux (x86_64) PHP version: 5.4.8 Package: Date/time related Bug Type: Bug Bug description:[PATCH] Incorrect/inconsistent day of week prior to the year 1600 Description: PHP timelib calculates the day of the week incorrectly for dates prior to the 1st of January 1600. Test script: --- Expected result: Date PHP OS -- --- --- 1599-12-30 Thu Thu 1599-12-31 Fri Fri 1600-01-01 Sat Sat 1600-01-02 Sun Sun Actual result: -- Date PHP OS -- --- --- 1599-12-30 Fri Thu 1599-12-31 Sat Fri 1600-01-01 Sat Sat 1600-01-02 Sun Sun -- Edit bug report at https://bugs.php.net/bug.php?id=63391&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63391&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63391&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63391&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63391&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63391&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63391&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63391&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63391&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63391&r=support Expected behavior: https://bugs.php.net/fix.php?id=63391&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63391&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63391&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63391&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63391&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63391&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63391&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63391&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63391&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63391&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63391&r=mysqlcfg
Bug #63380 [Asn]: Allocation via libxml does not use PHP's per-request allocator
Edit report at https://bugs.php.net/bug.php?id=63380&edit=1
ID: 63380
Updated by: tstarl...@php.net
Reported by:tstarl...@php.net
Summary:Allocation via libxml does not use PHP's per-request
allocator
Status: Assigned
Type: Bug
Package:XML related
Operating System: Linux
PHP Version:master-Git-2012-10-29 (Git)
Assigned To:rrichards
Block user comment: N
Private report: N
New Comment:
https://github.com/php/php-src/pull/223
Previous Comments:
[2012-10-29 03:25:17] tstarl...@php.net
Description:
Allocation via libxml does not use PHP's per-request allocator. So any memory
used by libxml will not be accounted against memory_get_usage() or memory_limit.
At Wikimedia we use libxml DOM trees to store wikitext parse trees, because
they are more compact in memory than the equivalent pure-PHP data structures.
When these parse trees are cached, the memory requirements can become
excessive, and the memory is typically not returned to the system after request
termination. Using xmlMemSetup() to set hook functions which use PHP's
per-request allocation functions will allow us to more effectively monitor and
limit the use of libxml in production.
I've developed a patch and will submit it to GitHub as a pull request.
Test script:
---
$doc = new DOMDocument;
for ( $i = 0; $i < 100 ; $i++ ) {
$doc->appendChild($doc->createElement('foo'));
}
print memory_get_usage()."\n";
Expected result:
312331440 (with debug and ZTS)
Actual result:
--
694256
--
Edit this bug report at https://bugs.php.net/bug.php?id=63380&edit=1
[PHP-BUG] Bug #63389 [NEW]: Missing context check on libxml_set_streams_context() causes memleak
From: felipe Operating system: PHP version: Irrelevant Package: XML related Bug Type: Bug Bug description:Missing context check on libxml_set_streams_context() causes memleak Description: See below. Test script: --- https://bugs.php.net/bug.php?id=63389&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63389&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63389&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63389&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63389&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63389&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63389&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63389&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63389&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63389&r=support Expected behavior: https://bugs.php.net/fix.php?id=63389&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63389&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63389&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63389&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63389&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63389&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63389&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63389&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63389&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63389&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63389&r=mysqlcfg
[PHP-BUG] Bug #63386 [NEW]: mysqli_connect_error may not include username
From: mark at invisionpower dot com Operating system: OS X 10.8.2 PHP version: 5.4.8 Package: MySQLi related Bug Type: Bug Bug description:mysqli_connect_error may not include username Description: If attempting to connect to a database using the MySQL Improved Extension using a username but a blank password, and that user does not exist, the error message does not specify the attempted username. See attached test script and expected/actual output. Test script: --- $mysqli = new mysqli( 'localhost', 'foo', '', 'dbname' ); echo $mysqli->connect_error; Expected result: Access denied for user 'foo'@'localhost' to database 'dbname' Actual result: -- Access denied for user ''@'localhost' to database 'dbname' -- Edit bug report at https://bugs.php.net/bug.php?id=63386&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63386&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63386&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63386&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63386&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63386&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63386&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63386&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63386&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63386&r=support Expected behavior: https://bugs.php.net/fix.php?id=63386&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63386&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63386&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63386&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63386&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63386&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63386&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63386&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63386&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63386&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63386&r=mysqlcfg
Bug #60840 [Asn->Nab]: undefined symbol: mysqlnd_debug_std_no_trace_funcs
Edit report at https://bugs.php.net/bug.php?id=60840&edit=1 ID: 60840 Updated by: johan...@php.net Reported by:public at grik dot net Summary:undefined symbol: mysqlnd_debug_std_no_trace_funcs -Status: Assigned +Status: Not a bug Type: Bug Package:PDO related Operating System: linux PHP Version:5.4SVN-2012-01-22 (snap) Assigned To:mysql Block user comment: N Private report: N New Comment: public at grik dot net, the issue is when building the extensions shared we can't decide what to do with mysqlnd, should that be built-in or shared, too? Or maybe the user has a different mysqlnd? - We leave this to the user. Previous Comments: [2012-06-14 10:03:03] public at grik dot net Johannes, thanks for the response, but according to http://php.net/ChangeLog-5.php "ext/mysql, mysqli and pdo_mysql now use mysqlnd by default." in 5.4 So the issues are: 1. Why should we explicitly enable the feature used by default? 2. How can we NOT use mysqlnd in debug mode, if it issues an error for missing mysqlnd_debug_std_no_trace_funcs? [2012-06-14 09:57:57] fausten at pw-internet dot de Hi, the package is going to build with mysqlnd by default: # cd /usr/ports/databases/php5-pdo_mysql && make config MYSQLND - Use MySQL Native Driver (Is selected by default) # make install clean After installation: The following line has been added to your /usr/local/etc/php/extensions.ini configuration file to automatically load the installed extension: extension=pdo_mysql.so So the extension sholud be loaded after restarting php. [2012-06-14 09:41:44] johan...@php.net When building the MySQL extensions you explicitly have to enable mysqlnd. i.e. --enable-mysqlnd=shared. If you build mysqlnd shared you have to remember to load it, too. I will look whether the build system can be made smarter and at least warn. I don't want to make the decision in there whether to build shared or static. If I'd make that decision I'd default to static mysqlnd. [2012-06-14 09:32:56] fausten at pw-internet dot de Hi, same problem here: # cd /usr/ports/database/php5-pdo_mysql && make install clean Build is successfully. % php foo.php PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20100525-debug/pdo_mysql.so' - /usr/local/lib/php/20100525-debug/pdo_mysql.so: Undefined symbol "mysqlnd_debug_std_no_trace_funcs" in Unknown on line 0 OS: FreeBSD 9.0 amd64 PHP: 5.4.3 builded from ports (# cd /usr/ports/lang/php5 %% make install clean) [2012-05-02 09:30:30] u...@php.net Don't assign to individuals if you mean "mysql". 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=60840 -- Edit this bug report at https://bugs.php.net/bug.php?id=60840&edit=1
Bug #63378 [Opn->Nab]: xmlreader libxml2 2.9.0 undefined symbol: xmlTextReaderSetup
Edit report at https://bugs.php.net/bug.php?id=63378&edit=1 ID: 63378 Updated by: fel...@php.net Reported by:spamik at yum dot pl Summary:xmlreader libxml2 2.9.0 undefined symbol: xmlTextReaderSetup -Status: Open +Status: Not a bug Type: Bug Package:XML Reader PHP Version:5.4.8 Block user comment: N Private report: N New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Not a PHP problem. Try a clean PHP build on your system again. Previous Comments: [2012-10-28 21:29:03] spamik at yum dot pl Description: datadata'; $xml->XML($xmldata); ?> php 5.4.8 compiled with libxml2 2.9.0 /usr/bin/php: symbol lookup error: /usr/bin/php: undefined symbol: xmlTextReaderSetup It works when php is compiled against libxml2 2.6.26 -- Edit this bug report at https://bugs.php.net/bug.php?id=63378&edit=1
Bug #63380 [Opn->Asn]: Allocation via libxml does not use PHP's per-request allocator
Edit report at https://bugs.php.net/bug.php?id=63380&edit=1
ID: 63380
Updated by: fel...@php.net
Reported by:tstarl...@php.net
Summary:Allocation via libxml does not use PHP's per-request
allocator
-Status: Open
+Status: Assigned
Type: Bug
Package:XML related
Operating System: Linux
PHP Version:master-Git-2012-10-29 (Git)
-Assigned To:
+Assigned To:rrichards
Block user comment: N
Private report: N
Previous Comments:
[2012-10-29 03:25:17] tstarl...@php.net
Description:
Allocation via libxml does not use PHP's per-request allocator. So any memory
used by libxml will not be accounted against memory_get_usage() or memory_limit.
At Wikimedia we use libxml DOM trees to store wikitext parse trees, because
they are more compact in memory than the equivalent pure-PHP data structures.
When these parse trees are cached, the memory requirements can become
excessive, and the memory is typically not returned to the system after request
termination. Using xmlMemSetup() to set hook functions which use PHP's
per-request allocation functions will allow us to more effectively monitor and
limit the use of libxml in production.
I've developed a patch and will submit it to GitHub as a pull request.
Test script:
---
$doc = new DOMDocument;
for ( $i = 0; $i < 100 ; $i++ ) {
$doc->appendChild($doc->createElement('foo'));
}
print memory_get_usage()."\n";
Expected result:
312331440 (with debug and ZTS)
Actual result:
--
694256
--
Edit this bug report at https://bugs.php.net/bug.php?id=63380&edit=1
[PHP-BUG] Bug #63384 [NEW]: Cannot override an abstract method with an abstract method
From: dagguh at gmail dot com
Operating system: Irrelevant
PHP version: 5.3.18
Package: Class/Object related
Bug Type: Bug
Bug description:Cannot override an abstract method with an abstract method
Description:
It is impossible to override an abstract method with another abstract
method.
This is useful if you are trying to indicate (to both IDE and other
developers)
that the overriden method returns type is expected to be a subclass of the
inherited method return type.
PS. Java allows it and it is generally a more restrictive language than
PHP.
Test script:
---
abstract class RuntimeExceptionReporter extends ExceptionReporter {
/**
* @return RuntimeException
*/
public abstract function getExceptionToReport();
// ... some operations specific to RuntimeException
}
abstract class ExceptionReporter {
/**
* @return Exception
*/
public abstract function getExceptionToReport();
// ... some operations on an Exception
}
Expected result:
Correct inheritance
Actual result:
--
Fatal error: Can't inherit abstract function
ExceptionReporter::getExceptionToReport() (previously declared abstract in
RuntimeExceptionReporter) in xxx on line yyy
--
Edit bug report at https://bugs.php.net/bug.php?id=63384&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63384&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63384&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63384&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63384&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63384&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63384&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63384&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63384&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63384&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63384&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63384&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63384&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63384&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63384&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63384&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63384&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63384&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63384&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63384&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63384&r=mysqlcfg
Bug #61613 [Com]: No PDO error if first SQL statement of a group is valid.
Edit report at https://bugs.php.net/bug.php?id=61613&edit=1
ID: 61613
Comment by: verger dot antoine at gmail dot com
Reported by:trebitzki at gmx dot net
Summary:No PDO error if first SQL statement of a group is
valid.
Status: Assigned
Type: Bug
Package:PDO related
Operating System: Mac OS X
PHP Version:5.3.10
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
Hi,
I have the same issue on 5.4.6 on Ubuntu 12.04 and PDO_MYSQL 5.5.24.
Di you have any idea where it comes from ? I had a look at the source from PDO
and also from MySQL C API but no clue and above all too hard to find the origin.
I saw that the issue has been assigned to mysql by ahar...@php.net but I don't
why exactly. Could you explain me ?
Antoine
Previous Comments:
[2012-08-28 22:09:08] angel dot koilov at gmail dot com
Same issue debian wheezy, php 5.4.4-4
[2012-08-01 19:40:01] jonwage at gmail dot com
I am experiencing the same issue. Tested on 5.3.5 and 5.3.10 currently.
[2012-04-11 23:27:03] trebitzki at gmx dot net
I'm working on 1and1 server with PDO Driver for MySQL, client library version
5.1.49; locally on Mac with PDO Driver for MySQL Client API version mysqlnd
5.0.7-dev - 091210 - $Revision: 304625 $. Both environments show this issue.
[2012-04-11 15:08:20] johan...@php.net
Which PDO driver are you using?
[2012-04-03 22:57:20] trebitzki at gmx dot net
Description:
I am submitting a group of two SQL statements to PDO. The first is valid, the
second has a syntax error. PDO should throw an exception but doesn't. It only
throws an exception when the first statement is invalid.
Test script:
---
//[symfony 1.4 environment]
$conn = Propel::getConnection();
$conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$pdo_statement = $conn->prepare('SELECT 1; invalidstatement');
$pdo_statement->execute();
Expected result:
I expect to have an error thrown since the group of statements has a syntax
error.
Actual result:
--
No error is thrown.
--
Edit this bug report at https://bugs.php.net/bug.php?id=61613&edit=1
Req #50815 [Wfx]: Implement 323 short password hash fallback in mysqlnd
Edit report at https://bugs.php.net/bug.php?id=50815&edit=1 ID: 50815 Updated by: u...@php.net Reported by:jd at cpanel dot net Summary:Implement 323 short password hash fallback in mysqlnd Status: Wont fix Type: Feature/Change Request Package:MySQL related Operating System: any PHP Version:5.3.1 Assigned To:mysql Block user comment: N Private report: N New Comment: I second Andrey: won't fix, http://sqlhack.com/ . Previous Comments: [2012-10-29 08:00:54] and...@php.net There is no such thing as discouraging. It is about updating the credentials, so they are more secure. Just use SET PASSWORD and hash the password again. [2012-10-26 17:18:09] toddr at cpanel dot net If you want to discourage use of the short password method, couldn't you just add a configure option to enable this and disable it by default? [2012-10-26 17:11:47] toddr at cpanel dot net If all MySQL 5 versions support this hashing scheme, Aren't you kinda overriding a user decision to enable short passwords on their MySQL server? It's also not clear when the failure happens what the problem is. [2010-08-27 06:00:08] ahar...@php.net Fix up the package to make this easier to search for. [2010-08-26 13:31:35] u...@php.net We mysql guys have no plans adding old insecure password stuff to mysqlnd. As it is assigned to us/me, I'm changing status to what shall be status from our/my perspective: won't fix. 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=50815 -- Edit this bug report at https://bugs.php.net/bug.php?id=50815&edit=1
Req #50815 [Wfx]: Implement 323 short password hash fallback in mysqlnd
Edit report at https://bugs.php.net/bug.php?id=50815&edit=1 ID: 50815 Updated by: and...@php.net Reported by:jd at cpanel dot net Summary:Implement 323 short password hash fallback in mysqlnd Status: Wont fix Type: Feature/Change Request Package:MySQL related Operating System: any PHP Version:5.3.1 Assigned To:mysql Block user comment: N Private report: N New Comment: There is no such thing as discouraging. It is about updating the credentials, so they are more secure. Just use SET PASSWORD and hash the password again. Previous Comments: [2012-10-26 17:18:09] toddr at cpanel dot net If you want to discourage use of the short password method, couldn't you just add a configure option to enable this and disable it by default? [2012-10-26 17:11:47] toddr at cpanel dot net If all MySQL 5 versions support this hashing scheme, Aren't you kinda overriding a user decision to enable short passwords on their MySQL server? It's also not clear when the failure happens what the problem is. [2010-08-27 06:00:08] ahar...@php.net Fix up the package to make this easier to search for. [2010-08-26 13:31:35] u...@php.net We mysql guys have no plans adding old insecure password stuff to mysqlnd. As it is assigned to us/me, I'm changing status to what shall be status from our/my perspective: won't fix. [2010-03-03 16:57:40] chris at geartech dot org I am running into this issue with mysqlnd as well; at my work we must keep old passwords on a few daemons to ensure backwards compatibility with proprietary software. MySQL's website (checking the 5.1 & 5.5 documentation) doesn't have the old password format deprecated in the newer versions, it's merely discouraged. While I agree that it is an insecure format and deprecating/removing support of it would be ideal, but it seems like support for this password scheme will exist in (major) future versions. 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=50815 -- Edit this bug report at https://bugs.php.net/bug.php?id=50815&edit=1
