[tahoe-dev] Fixed? Freebsd unparsable directory

[Nathan]

On Tue, May 6, 2008 at 9:22 AM, Ben Laurie <ben at links.org> wrote:
> 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
>

I second this concern.  Even if you want to reuse an IV, shouldn't the
wrapper force the caller to do this explicitly, for that specific
context?




>
>  > 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
>
>
> _______________________________________________
>  tahoe-dev mailing list
>  tahoe-dev at allmydata.org
>  http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
>