[tahoe-dev] [pycryptopp] #24: SHA256 failure on NetBSD with multiple segments

[pycryptopp]

#24: SHA256 failure on NetBSD with multiple segments
---------------------+------------------------------------------------------
Reporter:  warner    |           Owner:       
    Type:  defect    |          Status:  new  
Priority:  critical  |         Version:  0.5.1
Keywords:            |   Launchpad_bug:       
---------------------+------------------------------------------------------
 In [http://allmydata.org/trac/tahoe/ticket/738 tahoe#738], a user reported
 hash-validation failures on a certain sized file on NetBSD/i386. Working
 backwards, we were able to isolate the problem to a pycryptopp hash
 failure,
 as demonstrated in the following test:

 {{{
 expected = SHA256("a"*33 + "a"*95).hexdigest()
 s = SHA256("a"*33)
 s.update("a"*95)
 got = s.hexdigest()
 assert expected==got, (expected, got)
 }}}

 It would appear that two updates, in which the total number of bytes is a
 multiple of 128, and in which the first write is an odd number less than
 64,
 will cause this bug.

 I'll attach a file with a test case to add to the pycryptopp test suite
 that
 should exercise this problem.

 This was observed in an 0.5.14 tree, on a box described as "NetBSD fasty
 4.99.7 NetBSD 4.99.7 ... i386". The sha.cpp file was compiled with a
 command
 line of: {{{cc -pthread -fno-strict-aliasing -DNDEBUG -O2 -I/usr/include
 -I/usr/pkg/include -fPIC -I. -I/usr/pkg/include/python2.5 -c
 cryptopp/sha.cpp -o build/temp.netbsd-4.99.7-i386-2.5/cryptopp/sha.o
 -w}}}. (note that inline assembly was probably enabled). "cc" was {{{cc
 (GCC) 4.1.2 20060628 prerelease (NetBSD nb2 20060711)}}}, and "as" was
 {{{GNU assembler 2.16.1}}}.

-- 
Ticket URL: <http://allmydata.org/trac/pycryptopp/ticket/24>
pycryptopp <http://allmydata.org/trac/pycryptopp>
Python bindings for the Crypto++ library