[tahoe-dev] Fixed? Freebsd unparsable directory

[zooko]

Dear Ben Hyde:

Thank you very much for helping me debug this issue on FreeBSD.

On May 5, 2008, at 5:23 PM, Ben Hyde wrote:

> On May 5, 2008, at 6:18 PM, Ben Hyde wrote:
>> So that lead me to notice the my cryptopp is 5.4 (i.e. what freebsd
>> ports gives me); and that there was a newer version 5.5.2 - hand
>> installed that ... same result.
>
> Opps.  I was thinking dynamic linking; but doing pycryptopp testing
> again with a freshly unpacked tar ... all the tests pass.

Ah, so pycryptopp v0.3.0 doesn't link to libcryptopp.so at link time,  
so you upgrading from Crypto++ 5.4 to Crypto++ 5.5.2 didn't have any  
effect on the pycryptopp unit tests without also rebuilding pycryptopp.

That explains why your second test (quoted above) had "... same result".

However, rebuilding pycryptopp v0.3.0 linked against a newer version  
of Crypto++ should *not* have fixed the bug in question.  The bug in  
question is in this version of AES_init():

http://allmydata.org/trac/pycryptopp/browser/pycryptopp/cipher/ 
aesmodule.cpp?rev=133#L104

See the bug?  Consider this a challenge.  :-)  You can assume that  
the Crypto++ implementation is correct.

Ah, okay, so actually if you *did* confirm, as you said you did, that  
pycryptopp v0.3.0 exhibits incorrect AES cryption when built against  
Crypto++ v5.4, but correct when built against Crypto++ v5.5.2, then  
this does make sense.  I will assume that Crypto++ v5.5.2 does  
something different with the stack inside the constructor of  
CTR_Mode<AES>::Encryption.  (I guess that's another hint.)

I have now bundled pycryptopp-0.5.1 with the Tahoe source checkout.

More on this later -- I want to improve Tahoe, and our build/ 
configure/distribution/testing process, to reduce the likelihood of  
something like this happening again.

Thanks a lot!

Regards,

Zooko