Kristján Valur Jónsson krist...@ccpgames.com added the comment:
Found the issue and it wasn't with sha1.
Turned out that the code was doing somethign like
sha1(buffer(unicode('str'))) which exposed the endianness of the unicode
representation.
Sorry for wasting your time.
--
Scott Dial sc...@scottdial.com added the comment:
Got a test case that demonstrates a failure? Looks like it works to me...
$ uname -ip
sparc SUNW,Sun-Fire-280R
$ python -c 'import sys; print sys.byteorder'
big
$ python -c 'import sha; print sha.new(open(test, rb).read()).hexdigest()'
Kristján Valur Jónsson krist...@ccpgames.com added the comment:
Something is definietly weird on the PS3. I´ll give more concrete data soon.
(and yes, I may have misread the code)
--
___
Python tracker rep...@bugs.python.org
Changes by Jesús Cea Avión j...@jcea.es:
--
nosy: +jcea
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10430
___
___
Python-bugs-list mailing list
Nick Coghlan ncogh...@gmail.com added the comment:
If I was looking for opportunities for a compiler to do something weird, I'd
start with the TestEndianness macro (i.e. maybe it is incorrectly flagging the
Cell as little endian when it is actually big endian)
The endianness handling itself
Kristján Valur Jónsson krist...@ccpgames.com added the comment:
Yes, in my original myopic observation I was mistaken in thinking that we were
reading the digest out of the 5 entry int32 digest field in the SHAobject.
I´ve already verified that the Endianness field is correctly set. What I
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +gregory.p.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10430
___
___
Python-bugs-list
New submission from Kristján Valur Jónsson krist...@ccpgames.com:
in shamodule.c, the digest() method just creates a simple bytes string of the
digest. The digest is stored as an array of 32 bit integers in the native
representation. Therefore, the digest will be different on big- and
