[tahoe-dev] Fixed? Freebsd unparsable directory

[Ben Laurie]

zooko wrote:
> 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.

Presumably the issue is that defaultiv is out of scope by the time it is 
used.

A little surprised that:

a) a default IV exists at all

b) you are using it

> 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 don't think we should be relying on this presumption!

> 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.

I suggest that you should run the package self-tests even if you do not 
use your own versions of the packages.

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff