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 little-endian machines.

The specification (http://en.wikipedia.org/wiki/SHA-1) suggest that the digest should actually be big endian, so the standard implementation on most home machines is actually wrong

Actually, looking at the code, hexdigest() has the same problem!

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()'
851faf3199d27200abf2750c14ae6451696216a9
$ sha1sum -b test
851faf3199d27200abf2750c14ae6451696216a9 *test

# uname -ip
AMD Sempron(tm) Processor 2800+ AuthenticAMD
# python -c 'import sys; print sys.byteorder'
little
# python -c 'import sha; print sha.new(open("test", "rb").read()).hexdigest()'
851faf3199d27200abf2750c14ae6451696216a9
# sha1sum -b /tmp/test
851faf3199d27200abf2750c14ae6451696216a9 *test

I think your code analysis is wrong. Perhaps you missed the call to longReverse(), which does endianness byte-swapping, at the beginning of the sha_transform() that specifically is commented: "When run on a little-endian CPU we need to perform byte reversal on an array of longwords."

Something is definietly weird on the PS3.  I´ll give more concrete data soon.  (and yes, I may have misread the code)

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 looks fine to me, though.

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 thought was an obvious error due to people not using big-endian much, is probably much more subtle.

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.