[tahoe-dev] Need some input for Ubuntu packaging
David-Sarah Hopwood
david-sarah at jacaranda.org
Mon Jun 6 18:09:26 PDT 2011
On 07/06/11 01:17, Paul Hummer wrote:
> Hi folks-
>
> The context of this email is here:
>
> https://code.launchpad.net/~jtaylor/ubuntu/oneiric/tahoe-lafs/tahoe-lafs-fix/+merge/63631
>
>
> Some of the autodeps sort of stuff I purposefully patch out specifically
> because I make that sort of stuff static in the packaging metadata, and the
> setup usually ends up complicating things (and going out to the internet,
> which the Ubuntu buildds explicitly aren't allowed to do).
>
> I'm curious about stepping back on pycryptopp. I'm curious why we can't
> just update the pycryptopp instead of downgrading the pycryptopp library.
There is a good reason why Tahoe depends on at least pycryptopp 0.5.20
(on x86 and x86-64). It's documented in src/allmydata/_auto_deps.py:
# pycryptopp v0.5.20 fixes bugs in SHA-256 and AES on x86 or amd64
# (from Crypto++ revisions 470, 471, 480, 492).
Now, in
<https://bugs.launchpad.net/ubuntu/+source/tahoe-lafs/+bug/782461/comments/4>
Zooko said:
# ... since Ubuntu's distribution of pycryptopp uses the system (Ubuntu
# distribution of) Crypto++ then it is not vulnerable to that issue.
But hang on, how do we know that Tahoe will use the Ubuntu distribution
of pycryptopp? It will use the pycryptopp that is first on the sys.path
in the Tahoe process. The sys.path depends in an impossibly difficult-
to-predict way on the history of installations of Python packages (by
setuptools, other Python-specific installers, and OS package managers),
including Python packages that might seem completely unrelated. When Tahoe
starts, it will sanity-check that the version of the pycryptopp it imported
is >= 0.5.20. However, there is no direct check on which version of Crypto++
the imported pycryptopp is using.
I don't see what the difficulty is in upgrading the Ubuntu pycryptopp
package to 0.5.20. That is the simplest way for Tahoe to be as sure as
it can be (against accidental misconfigurations) that it is getting a
pycryptopp that will use a Crypto++ that fixes these SHA-256 and AES bugs.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 294 bytes
Desc: OpenPGP digital signature
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20110607/113d1005/attachment.pgp>
More information about the tahoe-dev
mailing list