[PHP-QA] Bug #64545 [Com]: PHP Error in ef93a93ee21bce9218188

2013-03-28 Thread ni...@php.net
Edit report at https://bugs.php.net/bug.php?id=64545&edit=1

 ID: 64545
 Comment by:     ni...@php.net
 Reported by:bobwei9 at hotmail dot com
 Summary:PHP Error in ef93a93ee21bce9218188
 Status: Closed
 Type:   Bug
 Package:Testing related
 Operating System:   Irrelevant
 PHP Version:master-Git-2013-03-28 (Git)
 Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

Thanks, fixed on 5.4 too.


Previous Comments:

[2013-03-28 17:32:16] bobwei9 at hotmail dot com

Please fix it in the PHP 5.4 branch too.


[2013-03-28 17:24:52] ni...@php.net

Automatic comment on behalf of nikic
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=b1a6a1703910d77ef7932cd4b03a36a4dbabc917
Log: Fix Bug #64545:PHP Error in ef93a93ee21bce9218188


[2013-03-28 17:15:26] bobwei9 at hotmail dot com

Description:

http://git.php.net/?p=php-
src.git;a=commitdiff;h=ef93a93ee21bce9218188d3f037cf55c5d2ae452

die is not a language construct, but a normal function. The skipif code here 
produces a parse error.







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=64545&edit=1

-- 
PHP Quality Assurance Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-QA] [PHP-BUG] Bug #67177 [NEW]: run-tests.php doesn't work well with LEAK

2014-05-02 Thread ni...@php.net
From: nikic
Operating system: 
PHP version:  5.6.0beta2
Package:  Testing related
Bug Type: Bug
Bug description:run-tests.php doesn't work well with LEAK

Description:

 * REPORT_EXIT_STATUS=1 results in exit=0 even though there are
FAILED&LEAKED tests.
 * There is no --show-mem or --show-leak option.


-- 
Edit bug report at https://bugs.php.net/bug.php?id=67177&edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fix.php?id=67177&r=trysnapshot54
Try a snapshot (PHP 5.5):   
https://bugs.php.net/fix.php?id=67177&r=trysnapshot55
Try a snapshot (trunk): 
https://bugs.php.net/fix.php?id=67177&r=trysnapshottrunk
Fixed in SVN:   https://bugs.php.net/fix.php?id=67177&r=fixed
Fixed in release:   https://bugs.php.net/fix.php?id=67177&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=67177&r=needtrace
Need Reproduce Script:  https://bugs.php.net/fix.php?id=67177&r=needscript
Try newer version:  https://bugs.php.net/fix.php?id=67177&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=67177&r=support
Expected behavior:  https://bugs.php.net/fix.php?id=67177&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=67177&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=67177&r=submittedtwice
register_globals:   https://bugs.php.net/fix.php?id=67177&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=67177&r=php4
Daylight Savings:   https://bugs.php.net/fix.php?id=67177&r=dst
IIS Stability:  https://bugs.php.net/fix.php?id=67177&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=67177&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=67177&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=67177&r=nozend
MySQL Configuration Error:  https://bugs.php.net/fix.php?id=67177&r=mysqlcfg


-- 
PHP Quality Assurance Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-QA] Bug #67177 [Com]: run-tests.php doesn't work well with LEAK

2014-05-02 Thread ni...@php.net
Edit report at https://bugs.php.net/bug.php?id=67177&edit=1

 ID: 67177
 Comment by:     ni...@php.net
 Reported by:    ni...@php.net
 Summary:run-tests.php doesn't work well with LEAK
 Status: Feedback
 Type:   Bug
 Package:Testing related
 PHP Version:5.6.0beta2
 Assigned To:tyrael
 Block user comment: N
 Private report: N

 New Comment:

@tyrael: A LEAK&FAIL test is only counted towards the number of leaked tests, 
but not towards the number of failed tests (otherwise it would be counted 
twice). That's why exit status will be 0 even though there were failed tests 
(that also happened to have memory errors).


Previous Comments:

[2014-05-02 07:28:19] tyr...@php.net

FAILED tests should fail the execution when REPORT_EXIT_STATUS=1 is set, could 
you show an exemple where that doesn't work?
when you call run-tests.php with -m, it will mark the leaking tests as LEAKED, 
which isn't FAILED, so that won't result in a non-zero exit status.
--show-mem sounds reasonable, and --show-all should also show the .mem if there 
is one.

----
[2014-05-02 07:00:39] ni...@php.net

Description:

 * REPORT_EXIT_STATUS=1 results in exit=0 even though there are FAILED&LEAKED 
tests.
 * There is no --show-mem or --show-leak option.







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=67177&edit=1

-- 
PHP Quality Assurance Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-QA] Bug #68238 [Com]: mcrypt_encode tests are broken

2014-10-15 Thread ni...@php.net
Edit report at https://bugs.php.net/bug.php?id=68238&edit=1

 ID: 68238
 Comment by:     ni...@php.net
 Reported by:gm dot outside+php at gmail dot com
 Summary:mcrypt_encode tests are broken
 Status: Not a bug
 Type:   Bug
 Package:Testing related
 Operating System:   Linux
 PHP Version:5.6.1
 Block user comment: N
 Private report: N

 New Comment:

The bug you linked has nothing to do with issue, it is a generic complaint from 
someone using broken crypto code, which is rejected by the stricter input 
requirements in PHP 5.6.

When you say that mcrypt_encrypt on your PHP 5.5.12 build works correctly, do 
you mean that it provides the correct output for this test script (whereas PHP 
5.6 does not)? This test was only added in PHP 5.6, so just running `make test` 
will not be enough to check it - you have to manually run the file from the 5.6 
tree.


Previous Comments:

[2014-10-15 18:36:06] gm dot outside+php at gmail dot com

Related To: Bug #67286


[2014-10-15 18:30:09] gm dot outside+php at gmail dot com

@nikic, I'm running the latest available mcrypt, which is 2.5.8.  The library 
passed all its internal tests.  Also, PHP 5.5.12 is working on the same box and 
does not have any issues with mcrypt_encode().

Additionally to this there are other bug reports pointing to the same issue, 
e.g. bug #67286 , so I would not dismiss this bug this easy.

Finally, the gcov test at php.net itself is failing the test on mcrypt.  The 
following tests was performed less than 2 days ago: 
http://gcov.php.net/viewer.php?version=PHP_HEAD&func=tests&file=ext%2Fmcrypt%2Ftests%2Fbug62102_rfc2144.phpt

So, let's try to pinpoint the issue? :)  Or at least let's fix the test case...

----
[2014-10-15 18:12:49] ni...@php.net

This is a bug in your mcrypt library, which does not properly support Cast-128 
with keys <= 80 bits. Padding the keys with NUL bytes is not the same, because  
Cast-128 uses only 12 rounds (instead of 16) if the key is <= 80 bits.

Updating your libmcrypt version will probably fix this.


[2014-10-15 17:32:24] gm dot outside+php at gmail dot com

I did more testing, and I was a bit wrong about the strlen() part.  Manually 
padding the keys with '\0' actually works, but the result does not match the 
ciphertext provided in RFC-2144 B.1 anymore.  Additionally to that I was wrong 
re: the keysize requirement for that cipher should be 16 bytes (128-bit) as 
cipher's name 'cast-128' suggests.

Once the keys are properly padded with '\0' to be 128-bit the test returns the 
following differences:

002+ 80-bit: 753de29f5d167d03
003+ 40-bit: f00b0530833d7444
002- 80-bit: eb6a711a2c02271b
003- 40-bit: 7ac816d16e9b302e

So, something else was also changed that the mcrypt extension no longer 
conforms to RFC-2144 B.1.


[2014-10-15 17:16:27] gm dot outside+php at gmail dot com

Description:

There was a recent commit 
(http://git.php.net/?p=php-src.git;a=commit;h=a861a3a93d89a50ce58e1ab1abef1eb501f97483)
 that changed behaviour of the mcrypt_encode() function.  After that commit the 
key is required to be at least the expected key length long, otherwise a 
warning message is issued and the mcrypt_encode() routine returns a failure.

The corresponding test in ext/mcrypt/tests/bug62102_rfc2144.php supplies 10 
bytes key instead of 16 for cast-128 80-bit encryption and 5 bytes key instead 
of 10 for cast-128 40-bit encryption.

A quick fix to the test would be to pad the keys with '\0' manually (RFC-2144 
B.1), e.g.

mcrypt_encrypt('cast-128', 
"\x01\x23\x45\x67\x12\x34\x56\x78\x23\x45\0\0\0\0\0\0", $plaintext, 'ecb')

but unfortunately due to the way changed code treats key data (as a null 
terminated string) and due to calculating the key size as strlen() of that 
string there is no way to satisfy the RFC-2144 B.1 since all trailing '\0' will 
be ignored.


Expected result:

That the RFC-2144 test would be passed with the explicitly specified vector and 
that mcrypt_encrypt() would honour the key argument as a binary string that can 
include '\0' anywhere in the string.

Actual result:
--
All trailing '\0' in the key argument are ignored, therefore it's impossible to 
pass RFC-2144 test to match section B.1.






--
Edit this bug report at https://bugs.php.net/bug.php?id=68238&edit=1

-- 
PHP Quality Assurance Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-QA] Bug #68238 [Com]: mcrypt_encode tests are broken

2014-10-15 Thread ni...@php.net
Edit report at https://bugs.php.net/bug.php?id=68238&edit=1

 ID: 68238
 Comment by:     ni...@php.net
 Reported by:gm dot outside+php at gmail dot com
 Summary:mcrypt_encode tests are broken
 Status: Not a bug
 Type:   Bug
 Package:Testing related
 Operating System:   Linux
 PHP Version:5.6.1
 Block user comment: N
 Private report: N

 New Comment:

Thank you for pointing out the outdated information in the documentation. I 
have just pushed some updates to the mcrypt_encrypt and mcrypt_decrypt docs; 
however it will take a few days to propagate to mirrors.

The test works on my machine (using libmcrypt 2.5.8-3.1 on Ubuntu) and also 
works on Travis (which is our CI platform). As libmcrypt is currently not 
maintained, it might be that the Cast-128 fixes have been applied by the distro 
vendor and may not be present in libmcrypt packages of other distros. There is 
nothing we (PHP) can do about this.

That your code using Rijndael-128 no longer works is unrelated to this problem 
(which only applies to Cast-128 with <= 80 bit keys, not to other ciphers like 
Rijndael). Presumably your code uses incorrect key sizes. If that is the case, 
you should either modify it to explicitly emulate the old \0 byte padding 
behavior or - which I would strongly recommend - fix your encryption code to 
use correctly sized keys.


Previous Comments:

[2014-10-15 19:11:31] gm dot outside+php at gmail dot com

Re: bug #67286 - well, the change to the behaviour as it is now is incompatible 
with the documentation at http://php.net/manual/en/function.mcrypt-encrypt.php, 
so there people will report bugs against this behaviour.  Moreover, the change 
is breaking things -- a warning message is one thing, but the function was 
changed to bail out with a failure upon a discovery of incorrect key size.  
This is the problem, actually.

Re: test case.  Yes, the test case was added on Mar 5th (you committed it 2 
days later), but it's currently broken in the HEAD, so I'm curious how one 
could do proper unit testing there :).

Re: 5.5.12 - no, I didn't run the exact same test, but OctoberCMS I'm running 
on that box stopped to work after switching to 5.6.1.  By default that 
application was using the MCRYPT_RIJNDAEL_128 cipher and that cipher was no 
longer working (the same application, the same mcrypt library, and the only 
change was PHP).  This is the reason I started to investigate.

Finally, I'm going to run the same test case on my PHP 5.5.12 and will report 
back shortly.  Still, it's strange to have a broken test for something that 
important as encryption.

--------
[2014-10-15 18:43:11] ni...@php.net

The bug you linked has nothing to do with issue, it is a generic complaint from 
someone using broken crypto code, which is rejected by the stricter input 
requirements in PHP 5.6.

When you say that mcrypt_encrypt on your PHP 5.5.12 build works correctly, do 
you mean that it provides the correct output for this test script (whereas PHP 
5.6 does not)? This test was only added in PHP 5.6, so just running `make test` 
will not be enough to check it - you have to manually run the file from the 5.6 
tree.


[2014-10-15 18:36:06] gm dot outside+php at gmail dot com

Related To: Bug #67286


[2014-10-15 18:30:09] gm dot outside+php at gmail dot com

@nikic, I'm running the latest available mcrypt, which is 2.5.8.  The library 
passed all its internal tests.  Also, PHP 5.5.12 is working on the same box and 
does not have any issues with mcrypt_encode().

Additionally to this there are other bug reports pointing to the same issue, 
e.g. bug #67286 , so I would not dismiss this bug this easy.

Finally, the gcov test at php.net itself is failing the test on mcrypt.  The 
following tests was performed less than 2 days ago: 
http://gcov.php.net/viewer.php?version=PHP_HEAD&func=tests&file=ext%2Fmcrypt%2Ftests%2Fbug62102_rfc2144.phpt

So, let's try to pinpoint the issue? :)  Or at least let's fix the test case...

--------
[2014-10-15 18:12:49] ni...@php.net

This is a bug in your mcrypt library, which does not properly support Cast-128 
with keys <= 80 bits. Padding the keys with NUL bytes is not the same, because  
Cast-128 uses only 12 rounds (instead of 16) if the key is <= 80 bits.

Updating your libmcrypt version will probably fix this.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report onlin