update pycryptopp to version 0.5.29-1 in lucid, maverick, natty

Bug #811721 reported by Julian Taylor
50
This bug affects 7 people
Affects Status Importance Assigned to Milestone
pycryptopp (Ubuntu)
Fix Released
Undecided
Unassigned
Natty
Fix Released
Medium
Unassigned
tahoe-lafs (Ubuntu)
Invalid
Undecided
Unassigned
Natty
Invalid
Undecided
Unassigned

Bug Description

requesting acknowledgement for update pycryptopp 0.5.17 to 0.5.29-1 in ubuntu 11.04 natty to fix tahoe

tahoe-lafs in natty requires a newer version of pycryptopp than is available in the natty repository.
It needs >= 0.5.20 but natty only has 0.5.17. See bug bug 782461
The reason for this requirement is a security vulnerability in the embedded libcrypto++. This does *not* affect natty as the pycryptopp package uses the system libcrypto++ which is fixed.
But in order to fix tahoe either the pycryptopp package must be updated or the version dependency of tahoe loosened.
The later option could be dangerous for users which have an old local vurnable version of pycryptopp installed, as tahoe would then not check for the problem anymore, so updating the packaged pycryptopp is preferable.

according to upstream the update should be safe as the majority of changes where build system related and the api was not broken.
Changelog:
http://tahoe-lafs.org/trac/pycryptopp/log/trunk/?action=stop_on_copy&mode=follow_copy&rev=772&stop_rev=&limit=128

The package builds in a clean natty chroot passes its testsuite and only has tahoe and python-beaker as rdepends, tahoe works fine with the new version and for beaker there where no problems reported in oneiric and debian testing either.

Please decide if the solution of upgrading pycryptopp is acceptable or if the route of reducing the version dependency in tahoe should be preferred

Related branches

Julian Taylor (jtaylor)
summary: - update pycryptopp to version 0.5.29-1
+ update pycryptopp to version 0.5.29-1 in natty
description: updated
Revision history for this message
Zooko Wilcox-O'Hearn (zooko) wrote : Re: update pycryptopp to version 0.5.29-1 in natty

I'm the primary maintainer of pycryptopp and a primary maintainer of tahoe-lafs, and I would be happy with upgrading pycryptopp in Ubuntu and less happy with patching tahoe-lafs's declarations of its dependencies.

Changed in pycryptopp (Ubuntu):
status: New → Confirmed
Revision history for this message
Daira Hopwood (daira) wrote :

What Zooko said. (I reviewed the changes to pycryptopp and they all look harmless or low-risk.)

Bear in mind that debian/control in Tahoe-LAFS also needs to be changed to depend on "python-pycryptopp (>= 0.5.20)" here: http://bazaar.launchpad.net/~jtaylor/ubuntu/oneiric/tahoe-lafs/fix-769935/view/head:/debian/control#L16 . Otherwise, if we are on an x86[-64] machine and the installed pycryptopp package declares its version as >= 0.5.14 but < 0.5.20, it won't be upgraded (if I understand the behaviour of .deb-based package managers correctly) and so the dependency in Tahoe's _auto_deps.py won't be met.

For future reference, it would be better if any Ubuntu- or Debian-patched version of pycryptopp (or any other Tahoe dependency) would declare its version in a way that allows us to recognize and accept it in the setuptools dependency language. For example, if the patched pycryptopp had declared itself as as 0.5.17.post1, then we could have written the Tahoe dependency as "pycryptopp == 0.5.17.post1, >= 0.5.20", and everything would have gone much more smoothly. The version numbers should follow http://www.python.org/dev/peps/pep-0396/ . This would probably be a good policy for Python packages in general.

Revision history for this message
Daira Hopwood (daira) wrote :
Revision history for this message
Zooko Wilcox-O'Hearn (zooko) wrote :

> This would probably be a good policy for Python packages in general.

That's a really good idea.

Changed in tahoe-lafs (Ubuntu):
status: New → Confirmed
Revision history for this message
Shaun Kuppe (shaun-kuppe) wrote :

Installed from 11.04 apt repo:

Package: python-pycryptopp
Priority: optional
Section: universe/python
Installed-Size: 1416
Maintainer: Ubuntu Developers <email address hidden>
Original-Maintainer: Zooko O'Whielacronx <email address hidden>
Architecture: amd64
Source: pycryptopp
Version: 0.5.17-1build1
Provides: python2.6-pycryptopp, python2.7-pycryptopp
Depends: python (<< 2.8), python (>= 2.6), python-support (>= 0.90.0), libc6 (>= 2.4), libcrypto++8, libgcc1 (>= 1:4.1.1), libstdc++6 (>= 4.1.1)
Filename: pool/universe/p/pycryptopp/python-pycryptopp_0.5.17-1build1_amd64.deb
Size: 393024
MD5sum: 0c481b23dd8d19d5718f40921c6e8c29
SHA1: 15f1479af5641931611389612ae1c8eed9e16ff1
SHA256: 79eeb16ab116d17ed32134e7087e2fcfab4850a775d108f8877f6d5ffe759d6a
Description: Python wrappers for the Crypto++ library
 PyCryptopp is a set of Python wrappers for a few of the best crypto algorithms
 from the Crypto++ library (including SHA-256, AES, RSA signatures and Elliptic
 Curve DSA signatures).
Homepage: http://allmydata.org/trac/pycryptopp
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu

Revision history for this message
Shaun Kuppe (shaun-kuppe) wrote :

This problem is still not fixed. A newer version of python-pycryptopp needs to be added to the 11.04 apt repository. After an apt-get update:

# apt-cache show python-pycryptopp
Package: python-pycryptopp
Priority: optional
Section: universe/python
Installed-Size: 1416
Maintainer: Ubuntu Developers <email address hidden>
Original-Maintainer: Zooko O'Whielacronx <email address hidden>
Architecture: amd64
Source: pycryptopp
Version: 0.5.17-1build1
Provides: python2.6-pycryptopp, python2.7-pycryptopp
Depends: python (<< 2.8), python (>= 2.6), python-support (>= 0.90.0), libc6 (>= 2.4), libcrypto++8, libgcc1 (>= 1:4.1.1), libstdc++6 (>= 4.1.1)
Filename: pool/universe/p/pycryptopp/python-pycryptopp_0.5.17-1build1_amd64.deb
Size: 393024
MD5sum: 0c481b23dd8d19d5718f40921c6e8c29
SHA1: 15f1479af5641931611389612ae1c8eed9e16ff1
SHA256: 79eeb16ab116d17ed32134e7087e2fcfab4850a775d108f8877f6d5ffe759d6a
Description: Python wrappers for the Crypto++ library
 PyCryptopp is a set of Python wrappers for a few of the best crypto algorithms
 from the Crypto++ library (including SHA-256, AES, RSA signatures and Elliptic
 Curve DSA signatures).
Homepage: http://allmydata.org/trac/pycryptopp
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu

Revision history for this message
Daira Hopwood (daira) wrote :

Bug 843000 was a duplicate.

Revision history for this message
thearthur (arthur-ulfeldt) wrote :

With 11.10 coming soon is this bug still in the works for 11.04?

Revision history for this message
Clint Byrum (clint-fewbar) wrote :

thearthur, typically we don't update to new upstream versions unless they are *purely* bug fix releases. It sounds to me like this might change the API of pycryptopp, which is unacceptable as a Stable Release Update (https://wiki.ubuntu.com/StableReleaseUpdates). If, however, you can show that it doesn't change the API, it can be considered.

If tahoe-lafs doesn't work with this version of the API, then it should be patched, but not the other way around.

I'm marking the main bug task as Fix Released for both products, since this is no longer an issue as of Oneiric. Marking Natty as Confirmed for tahoe-lafs, but Invalid for pycryptopp since as far as I can tell this isn't a bug in it, but rather a bug in something using its API. If I have misunderstood or misstated the problem, please feel free to change the status back to Confirmed and state the reasons.

Changed in pycryptopp (Ubuntu):
status: Confirmed → Fix Released
Changed in tahoe-lafs (Ubuntu):
status: Confirmed → Invalid
Changed in pycryptopp (Ubuntu Natty):
status: New → Invalid
Changed in tahoe-lafs (Ubuntu Natty):
status: New → Confirmed
Revision history for this message
Clint Byrum (clint-fewbar) wrote :

I did, in fact, misunderstand the original request, on re-reading it I see that the inclination is that the API has not been changed and upstream has asserted as much. Reversing my position then, and marknig this as Invalid in tahoe-lafs, and Confirmed in pycryptopp.

The next step would be for somebody to pick up the bug and actually produce a debdiff or bzr merge proposal to update natty to this version.

Changed in pycryptopp (Ubuntu Natty):
status: Invalid → Confirmed
Changed in tahoe-lafs (Ubuntu Natty):
status: Confirmed → Invalid
Changed in pycryptopp (Ubuntu Natty):
importance: Undecided → Medium
Revision history for this message
Martin Pitt (pitti) wrote :

As tahoe is the only reverse dependency of this package, this looks acceptable to me.

Changed in pycryptopp (Ubuntu Natty):
status: Confirmed → Fix Committed
tags: added: verification-needed
Revision history for this message
Martin Pitt (pitti) wrote : Please test proposed package

Hello Julian, or anyone else affected,

Accepted pycryptopp into natty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Revision history for this message
pataquets (pataquets) wrote : Re: update pycryptopp to version 0.5.29-1 in natty

I've 2 natty boxes and updated pycryptopp from -proposed using apt.
I've set up a 2 node grid and everything seems to work fine.
Just dumped a handful of files/dirs, deleted some shares, verified/repaired successfully and ran some 'tahoe backup'.
If someone can point to some thorough test procedure, please do.
HTH.

Martin Pitt (pitti)
tags: added: verification-done
removed: verification-needed
Revision history for this message
Daira Hopwood (daira) wrote :

> If someone can point to some thorough test procedure, please do.

The test suite can be run using 'python setup.py trial'. Thanks for the manual testing; the test suite isn't intended to replace that.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package pycryptopp - 0.5.29-0ubuntu0.1

---------------
pycryptopp (0.5.29-0ubuntu0.1) natty-proposed; urgency=low

  * New upstream release. (LP: #811721)
  * refresh patches
    - add new patch from debian to not ship extraversion.h
 -- Julian Taylor <email address hidden> Wed, 05 Oct 2011 19:32:34 +0200

Changed in pycryptopp (Ubuntu Natty):
status: Fix Committed → Fix Released
Revision history for this message
Zooko Wilcox-O'Hearn (zooko) wrote :

"add new patch from debian to not ship extraversion.h"

Is there a URL for this patch from debian? I would like to see what this change is. Thank you!

Revision history for this message
Julian Taylor (jtaylor) wrote :

the embedded cryptopp is not used so the extraversion.h must not be shipped.
http://patch-tracker.debian.org/package/pycryptopp/0.5.29-1

that may be something you could apply upstream for the non-embedded build.

Revision history for this message
pataquets (pataquets) wrote :

Just for the record, attached are the 2 node test runs.
As per https://tahoe-lafs.org/trac/tahoe-lafs/wiki/AdvancedInstall#point8, tested by running 'tahoe debug trial'.

Revision history for this message
Zooko Wilcox-O'Hearn (zooko) wrote :

Thank you very much for the testing, Alfonso.

By the way, I noticed that this wiki page -- https://tahoe-lafs.org/trac/tahoe-lafs/wiki/OSPackages -- hasn't been updated to show the existence of Oneiric.

Revision history for this message
Daira Hopwood (daira) wrote :

'tahoe debug trial' is indeed the correct way to run the tests for the installed version.
The following failure:

twisted.trial.unittest.FailTest: We seem to be testing the code at '/usr/lib/pymodules',
(according to the source filename '/usr/lib/pymodules/python2.7/allmydata/__init__.pyc'),
but expected to be testing the code at '/home/eutopia'.
Please run the tests from the root of the Tahoe-LAFS distribution.

is an upstream bug and can be ignored in this particular case.

Revision history for this message
pataquets (pataquets) wrote :

I don't remember what dir from I tested.
Now from ~/.tahoe:
$ tahoe debug trial

Revision history for this message
Evan Broder (broder) wrote :

Opening new tasks on this for Lucid and Maverick; they released with the same old version of pycryptopp as Natty, so this seems like it would still be applicable for them.

(This is presently relevant for a backport request - bug #834361 - wihch is currently uninstallable because of Lucid and Maverick's old versions of pycryptopp)

no longer affects: tahoe-lafs (Ubuntu Lucid)
no longer affects: tahoe-lafs (Ubuntu Maverick)
summary: - update pycryptopp to version 0.5.29-1 in natty
+ update pycryptopp to version 0.5.29-1 in lucid, maverick, natty
Revision history for this message
Julian Taylor (jtaylor) wrote :

the tahoe versions in maverick and lucid work fine with the available pycryptopp. This is no reason to do an SRU.

if you want to backport tahoe-lafs then also backport pycryptop.

Julian Taylor (jtaylor)
no longer affects: pycryptopp (Ubuntu Lucid)
no longer affects: pycryptopp (Ubuntu Maverick)
Revision history for this message
Martin Pitt (pitti) wrote :

Rejecting pycryptopp maverick upload because of comment 23 and maverick is three months before EOL.

Revision history for this message
Clint Byrum (clint-fewbar) wrote :

Indeed, I see no valid high priority bug to give reason to update lucid as well... if the lib needs to be backported, let it be done in backports. Rejected lucid-proposed upload.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.