Please review https://bugs.php.net/bug.php?id=61291
And attached patch....
Without the patch
37 PASSED TESTS
0 SKIPPED TESTS
2 FAILED TESTS:
mhash_001.phpt
mhash_003.phpt
With the patch
34 PASSED TESTS
0 SKIPPED TESTS
5 FAILED TESTS:
hash_copy_001.phpt
hash_file_basic1.phpt
hash_hmac_basic.phpt
hash_hmac_file_basic.phpt
tiger.phpt
But it seems the failing tests were introduce after this regression...
Perhaps, the new result is the right one... but I don't find any other
tool to check it... (it this case mhash_001.phpt and mhash_003.phpt have
to be fixed)
Regards,
Remi
Le 05/03/2012 17:44, Remi Collet a écrit :
Perhaps, the new result is the right one... but I don't find any other
tool to check it...
Using a simple C program (linked against libmash)
Hash: fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39
So the result from php <= 5.3.10 seems the right one.
Using a simple C program (linked against libmash)
Hash: fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39
So the result from php <= 5.3.10 seems the right one.
Sorry for the delay, but I already explained the issue in
the bug report: https://bugs.php.net/bug.php?id=61291
Thanks anyway,
Mike
Le 08/03/2012 09:03, Michael Wallner a écrit :
Using a simple C program (linked against libmash)
Hash: fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39
So the result from php <= 5.3.10 seems the right one.
Sorry for the delay, but I already explained the issue in
the bug report: https://bugs.php.net/bug.php?id=61291
Thanks, for the explanation.
I raised this issue, because of 2 failing tests.
Another test (because Interoperability seems important)
$ perl -e 'use Digest::Tiger;my $hexhash =
Digest::Tiger::hexhash("");print $hexhash."\n";'
3293AC630C13F0245F92BBB1766E16167A4E58492DDE73F3
$ php -r 'echo hash("tiger192,3", "")."\n";'
3293ac630c13f0245f92bbb1766e16167a4e58492dde73f3
So, this seems ok.
But mhash_001.phpt and mhash_003.phpt should not fail
(if we want a great PHP with 0 test failed).
As this tests seems to be old ones from old mhash extension,
they probably should be tagged as "expected failed" with a message such
as "Compatibility break with php < 5.4.0"
Best regards.
Thanks anyway,
Mike
2012/3/8 Remi Collet remi@fedoraproject.org
But mhash_001.phpt and mhash_003.phpt should not fail
(if we want a great PHP with 0 test failed).
Hi, all
That's what I would like to have ...
It would be perfect if new versions were not brought out if some tests
still fail.
I read some posts in the past before I decided to join this
mailing-list where people were laughing about bugfix-releases like
5.3.7 ...
Anyways: I want a great PHP with 0 failing tests - not because the
amount should be 0 but because no bugs are known/testable.
Bye
Simon
Le 08/03/2012 09:03, Michael Wallner a écrit :
Sorry for the delay, but I already explained the issue in
the bug report: https://bugs.php.net/bug.php?id=61291Thanks, for the explanation.
I'm still concerned about the idea that the output of a hash function
would change from one minor release to another, frankly, whether the
old output was right or wrong. That seems like the sort of thing users
would rely on being very, very stable.
But mhash_001.phpt and mhash_003.phpt should not fail
(if we want a great PHP with 0 test failed).As this tests seems to be old ones from old mhash extension,
they probably should be tagged as "expected failed" with a message such
as "Compatibility break with php < 5.4.0"
Agreed. I'm happy to mark them as XFAIL if that's what's expected. Mike?
Adam
Agreed. I'm happy to mark them as XFAIL if that's what's expected. Mike?
Adam
If the 5.4 behavior is deemed correct for 5.4+, then the expected output
should be updated for 5.4+ tests - they should not be XFAIL.
The UPGRADING file, migration doc, and any specific doc should be updated
with comments about the change.
Chris
--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
Le 08/03/2012 09:03, Michael Wallner a écrit :
Sorry for the delay, but I already explained the issue in
the bug report: https://bugs.php.net/bug.php?id=61291
Thanks, for the explanation.
I'm still concerned about the idea that the output of a hash function
would change from one minor release to another, frankly, whether the
old output was right or wrong. That seems like the sort of thing users
would rely on being very, very stable.
It'd be worse to keep the wrong behavior, providing as tiger what it is not.
What can be done is to add a "tiger192,3-broken php5.4" hash for BC of
those which may have used the new one.
It's serious enough so I'd consider it a factor for a new minor in short
time,
but not for setting in stone a wrong behavior.
It'd be worse to keep the wrong behavior, providing as tiger what it is not.
What can be done is to add a "tiger192,3-broken php5.4" hash for BC of
those which may have used the new one.
It's serious enough so I'd consider it a factor for a new minor in short
time, but not for setting in stone a wrong behavior.
wat?
The new hashes are correct. I'm awfully sorry that there has been so much
trouble with the tiger hashes, but it happened and cannot be undone.
--
Regards,
Mike
wat?
The new hashes are correct. I'm awfully sorry that there has been so much
trouble with the tiger hashes, but it happened and cannot be undone.
Whops, sorry. I got confused on this thread.
Change the order of what I said, then. Let the correct implementation stay
and add a legacy option for reversed tiger (although reversing 8 byte
chunks
seem easy to do in userland).