#49561 [NEW]: mcrypt warns about having no IV in ECB mode
From: terrafr...@php.net Operating system: PHP version: 5.2.10 PHP Bug Type: mcrypt related Bug description: mcrypt warns about having no IV in ECB mode Description: mcrypt complains about their being no IV even if ECB mode is being used. Since ECB mode doesn't use IVs, it seems like no such warning should be produced. Bug #43143 is fairly similar to this one, except that that one produced a slightly different error. Also, that one was closed on the basis that it had been fixed. Reproduce code: --- Expected result: I would expect that to just run its course and output nothing. Actual result: -- I get the following: Warning: mcrypt_generic_init(): Iv size incorrect; supplied length: 0, needed: 16 in C:\php\test.php on line 3 -- Edit bug report at http://bugs.php.net/?id=49561&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49561&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49561&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49561&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49561&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49561&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49561&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49561&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49561&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49561&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49561&r=support Expected behavior: http://bugs.php.net/fix.php?id=49561&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49561&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49561&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49561&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49561&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49561&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49561&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49561&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49561&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49561&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49561&r=mysqlcfg
#49738 [NEW]: calling mcrypt after mcrypt_generic_deinit crashes
From: terrafr...@php.net
Operating system: Windows XP
PHP version: 5.2.11
PHP Bug Type: mcrypt related
Bug description: calling mcrypt after mcrypt_generic_deinit crashes
Description:
In bug # 41252, it was observed that, in PHP4, calling mcrypt_generic()
before calling mcrypt_module_open() would cause PHP4 to crash. PHP5
apparently had extra checks to protect against this that were backported.
These extra checks, however, do not appear to be sufficient, as the
following reproduce code demonstrates.
Sure, calling mcrypt_generic_deinit() before calling mcrypt_generic is
probably not something you ought to be doing, anyway, but I still don't
think it ought to crash PHP.
Reproduce code:
---
Expected result:
Warning: mcrypt_generic(): Operation disallowed prior to
mcrypt_generic_init() in {filename} on line 5
Actual result:
--
It crashes.
--
Edit bug report at http://bugs.php.net/?id=49738&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49738&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49738&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49738&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49738&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49738&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49738&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49738&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49738&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49738&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49738&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49738&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49738&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49738&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49738&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49738&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49738&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49738&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49738&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49738&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49738&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49738&r=mysqlcfg
#47108 [Opn]: 0xAE breaks DOMDocument's loadHTML
ID: 47108 User updated by: terrafr...@php.net Reported By: terrafr...@php.net Status: Open Bug Type: DOM XML related Operating System: Windows XP PHP Version: 5.2.8 New Comment: That makes sense. I updated the script to iterate through the problem characters and the ones you mentioned are included. Other problem characters include 0x26, 0x3C, 0x3E, 0xA4, 0xA5 and 0xAA. The first three make sense - they correspond to &, <, and >, respectively. The latter three don't make as much sense to me. Also, it seems to me that it ought to fail more gracefully than it does - you wouldn't expect your browser to ignore all HTML after an invalid character is encountered and it seems to me like this shouldn't, either. Per your suggestion, I've filed a bug report on libxml2 here: http://bugzilla.gnome.org/show_activity.cgi?id=567885 Not sure if that's the appropriate bug tracker, though. Also, it seems like reproducing the bug using the language libxml2 is intended as a library for would be prudent, but alas, I don't have any C/C++ compilers on this computer. Previous Comments: [2009-01-15 02:53:45] typoon at gmail dot com The explanation to this might be the fact that ISO-8859-7 does not have the character 0xAE. When libxml tries to convert it, an error is thrown because of this. References: http://www.itscj.ipsj.or.jp/ISO-IR/227.pdf http://en.wikipedia.org/wiki/ISO_8859-7 Checking the PDF you will see 0xAE is not assigned. Quoting wikipedia: "Code values 001F, 7F, 809F, AE, D2 and FF are not assigned to characters by ISO/IEC 8859-7." More information and other reference can also be found on google. My 2 cents then are that this is not a bug at all. If you still think it is, the we might need to open a bug report for the libxml team as this is an error generated inside libxml, not PHP. Regards, Henrique -------- [2009-01-14 20:08:27] terrafr...@php.net Description: All HTML after chr(0xAE) (if present) is ignored by DOMDocument's loadHTML(), even if chr(0xAE) is a valid character per the HTML's charset. In the Reproduce code, replace chr(0xAE) with chr(0xAF) or chr(0xAD) or just remove it all together, and it works. Further, if you echo out $str and copy / paste the HTML into validator.w3.org, it's valid HTML, even with the chr(0xAE). Reproduce code: --- http://www.w3.org/TR/html4/strict.dtd";> test a' . chr(0xAE) . 'z '; $xml = new DOMDocument(); $xml->loadHTML($str); echo $xml->saveHTML(); Expected result: a�z Actual result: -- Warning: DOMDocument::loadHTML() [domdocument.loadhtml]: input conversion failed due to input error, bytes 0xAE 0x7A 0x7A 0x7A in C:\htdocs\test.php on line 14 Warning: DOMDocument::loadHTML() [domdocument.loadhtml]: input conversion failed due to input error, bytes 0xAE 0x7A 0x7A 0x7A in C:\htdocs\test.php on line 14 Warning: DOMDocument::loadHTML() [domdocument.loadhtml]: htmlCheckEncoding: encoder error in Entity, line: 4 in C:\htdocs\test.php on line 14 Warning: DOMDocument::loadHTML() [domdocument.loadhtml]: input conversion failed due to input error, bytes 0xAE 0x7A 0x7A 0x7A in C:\htdocs\test.php on line 14 a -- Edit this bug report at http://bugs.php.net/?id=47108&edit=1
[PHP-BUG] Bug #52924 [NEW]: resource type set to empty after bad mcrypt_generic_init call
From: Operating system: Windows 7 PHP version: 5.3.3 Package: mcrypt related Bug Type: Bug Bug description:resource type set to empty after bad mcrypt_generic_init call Description: Calling mcrypt_generic_init() with bad values changes the resource type from mcrypt to Unknown. It seems like what should happen is that the resource type should remain the same and that mcrypt_generic_init should simply do nothing. Maybe output a warning (as it currently does) but not change the resource type. A bad call to curl_setopt(), for example, doesn't change the resource type from curl to Unknown as demonstrated thusly: Per that it doesn't seem like a bad call to mcrypt_generic_init() ought to change anything either. Test script: --- Expected result: resource(4) of type (mcrypt) Actual result: -- resource(4) of type (Unknown) -- Edit bug report at http://bugs.php.net/bug.php?id=52924&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52924&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52924&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52924&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52924&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52924&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52924&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52924&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52924&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52924&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52924&r=support Expected behavior: http://bugs.php.net/fix.php?id=52924&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52924&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52924&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52924&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52924&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52924&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52924&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52924&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52924&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52924&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52924&r=mysqlcfg
Bug #60936 [Com]: openssl_verify does not work ok.
Edit report at https://bugs.php.net/bug.php?id=60936&edit=1 ID: 60936 Comment by: terrafr...@php.net Reported by:baylina at uniclau dot com Summary:openssl_verify does not work ok. Status: Not a bug Type: Bug Package:OpenSSL related Operating System: Any PHP Version:5.3.9 Block user comment: N Private report: N New Comment: It's not an OpenSSL issue either. Both PHP and OpenSSL are behaving as they should. "openssl rsautl -verify" is decrypting test_err.sig and checks to see if the hash contained within the ciphertextmatches test_err.sha1. That's not what "openssl dgst" or openssl_verify() do. They just verify the hash. Hash verification is it's own operation in the PKCS#1 standards distinct from decryption. That the second example yields a match is just dumb luck. Previous Comments: [2012-01-31 07:56:43] paj...@php.net Openssl issue (if any), not php. [2012-01-31 07:35:28] baylina at uniclau dot com I have investigated a litle more, and if you do $ openssl dgst -sha1 -verify test.pub -signature test_ok.sig test_ok.txt Verified OK $openssl dgst -sha1 -verify test.pub -signature test_err.sig test_err.txt Verification Failure So it seems that it is an openSSL problem. [2012-01-31 00:12:35] baylina at uniclau dot com Description: Some times, openssl_verify does not recognize a valid signature. The same input in the openssl command line works ok. See the case. You can verify with command line ssh that both signatures are ok: $ echo "-BEGIN PUBLIC KEY- MIGeMA0GCSqGSIb3DQEBAQUAA4GMADCBiAKBgGLgfmIN4O+aqfPGN1BkWW1hzCdj XqozEKyFnOTWCyp+H301nILC6JFV1WAEQnCZE/B8VTArlSYnOySU+MjU11jRSYTz nHokHLhCVkH/o/4ZqL1s0rtoJ62f6Loc3mZHRX7l2PJGTXNQJGTNRTh1kdJthA3S LMwa4ReOEyjIG7e7AgMBAAE= -END PUBLIC KEY-" > test.pub $ echo -n "1327943790" > test_err.txt $ openssl dgst -sha1 -binary -out test_err.sha1 test_err.txt $ echo "SEjTquEPcqY0V90KYvDi7ofGiKlc53T4XzHwHtIgcN5wuOg4JxffK trLN9Tq+8c/045m15JXULJUMkN7fdDUqtxFyIBSEt4nqhvZgLDVQBIBXJRF8 c32CBaLsG837hZra8/nD5b4T+sCyEXRUMmcfflhJiMIr7l72sOxgRmzTw==" > test_err.sig.64 $ base64 -D -i test_err.sig.64 -o test_err.sig $ openssl rsautl -verify -inkey test.pub -pkcs -pubin -in test_err.sig -out test_err.sha1.calc $ hexdump test_err.sha1 000 d8 44 89 0c 34 cb 0d 64 23 28 56 56 85 25 c8 46 010 f4 e8 f8 3d 014 $ hexdump test_err.sha1.calc 000 30 21 30 09 06 05 2b 0e 03 02 1a 05 00 04 14 d8 010 44 89 0c 34 cb 0d 64 23 28 56 56 85 25 c8 46 f4 020 e8 f8 3d 023 // You can see that the last bytes (the dgst) are the same. $ echo -n "1327943823" > test_ok.txt $ openssl dgst -sha1 -binary -out test_ok.sha1 test_ok.txt $ echo "GURbsl4CFPCG83RCZxsEpoRleXicXQhH1OC4Fk77b7EMj2g8aHUhD/L+sm oGSVpuEwup1fmkZBADXwBel8UKsmxgTLRX+vlGgyTr1XPqqHFNjtL33fd5 7NuKBqaJjwSp7D5xVMeVdQtQQbsKuKx5AvOPPyZfdtdyoJw/all1tl4=" > test_ok.sig.64 $ base64 -D -i test_ok.sig.64 -o test_ok.sig $ openssl rsautl -verify -inkey test.pub -pkcs -pubin -in test_ok.sig -out test_ok.sha1.calc $ hexdump test_ok.sha1 000 08 a8 55 9c d4 43 f9 cb ec 9f 04 f4 f2 dc aa 1f 010 7f e9 e1 11 014 $ hexdump test_ok.sha1.calc 000 30 21 30 09 06 05 2b 0e 03 02 1a 05 00 04 14 08 010 a8 55 9c d4 43 f9 cb ec 9f 04 f4 f2 dc aa 1f 7f 020 e9 e1 11 023 Test script: --- Expected result: 1 1 Actual result: -- 0 1 -- Edit this bug report at https://bugs.php.net/bug.php?id=60936&edit=1
[PHP-BUG] Bug #63752 [NEW]: foreach increments pointer used by current() once
From: terrafr...@php.net
Operating system: Windows 7
PHP version: 5.4.9
Package: Arrays related
Bug Type: Bug
Bug description:foreach increments pointer used by current() once
Description:
foreach seems to increment the pointer used by current() once even if
foreach
loops multiple times. Seems to me that it should not increment it at all or
increment it multiple times. Not once and that's it.
Test script:
---
$elem) {
echo "$key = $elem"; echo ' = ';
var_dump(current($a));
}
?>
Expected result:
0 = 1 = int(1)
1 = 2 = int(1)
2 = 3 = int(1)
3 = 4 = int(1)
4 = 5 = int(1)
Actual result:
--
0 = 1 = int(2)
1 = 2 = int(2)
2 = 3 = int(2)
3 = 4 = int(2)
4 = 5 = int(2)
--
Edit bug report at https://bugs.php.net/bug.php?id=63752&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63752&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63752&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63752&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63752&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63752&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63752&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63752&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63752&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63752&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63752&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63752&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63752&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63752&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63752&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63752&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63752&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63752&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63752&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63752&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63752&r=mysqlcfg
[PHP-BUG] Bug #64246 [NEW]: stream_metadata constants not defined
From: terrafr...@php.net Operating system: Windows 7 PHP version: 5.4.11 Package: Streams related Bug Type: Bug Bug description:stream_metadata constants not defined Description: <http://www.php.net/manual/en/streamwrapper.stream-metadata.php> mentions a bunch of constants but none appear to be defined. Test script: --- https://bugs.php.net/bug.php?id=64246&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64246&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64246&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64246&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64246&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64246&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64246&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64246&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64246&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64246&r=support Expected behavior: https://bugs.php.net/fix.php?id=64246&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64246&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64246&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64246&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64246&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64246&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64246&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64246&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64246&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64246&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64246&r=mysqlcfg
