Description of problem: When fwbackups is used: /usr/lib/python2.6/site-packages/Crypto/Util/randpool.py:40: RandomPool_DeprecationWarning: This application uses RandomPool, which is BROKEN in older releases. See http://www.pycrypto.org/randpool-broken RandomPool_DeprecationWarning) Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Use fwbackups 2. 3. Actual results: Message: /usr/lib/python2.6/site-packages/Crypto/Util/randpool.py:40: RandomPool_DeprecationWarning: This application uses RandomPool, which is BROKEN in older releases. See http://www.pycrypto.org/randpool-broken RandomPool_DeprecationWarning) Expected results: No such message Additional info:
Reassigning to python-crypto - fwbackups imports paramiko (which fwbackups requires for SFTP access) and paramiko requires python-crypto. I co-maintain python-crypto so I'll be able to take a look at this soon.
http://lists.dlitz.net/pipermail/pycrypto/2008q3/000020.html looks relevant. I think this should be fixed in paramiko rather than patching out the deprecation warning in python-crypto.
(In reply to comment #2) > http://lists.dlitz.net/pipermail/pycrypto/2008q3/000020.html looks relevant. I > think this should be fixed in paramiko rather than patching out the deprecation > warning in python-crypto. Agreed... For some reason I was thinking that pycrypto was using RandomPool, but that doesn't make any sense. The problem definitely needs to be resolved in paramiko. It seems that paramiko does use RandomPool, but fixes the problem on its own. This is the description of StrongLockingRandomPool in paramiko/rng.py: """Wrapper around RandomPool guaranteeing strong random numbers. Crypto.Util.randpool.RandomPool will silently operate even if it is seeded with little or no entropy, and it provides no prediction resistance if its state is ever compromised throughout its runtime. It is also not thread-safe. This wrapper augments RandomPool by XORing its output with random bits from the operating system, and by controlling access to the underlying RandomPool using an exclusive lock. """ This file was written by the pycrypto maintainer himself: http://www.lag.net/pipermail/paramiko/2008-April/000678.html Until Paramiko adopts the new API, one possible solution would be to simply suppress the warning as done in the bzr-installers-mac: https://bugs.launchpad.net/bzr-mac-installers/+bug/507762/comments/9
Is the patch attached to http://www.lag.net/pipermail/paramiko/2008-April/000679.html not suitable for use right now?
(In reply to comment #4) > Is the patch attached to > http://www.lag.net/pipermail/paramiko/2008-April/000679.html not suitable for > use right now? That patch has already been applied, the problem is that this the security hazard of using RandomPool was negated by reading data from the OS-specific RNG (ie /dev/urandom) and using that to XORing the RandomPool output. The import is still there so Python issues the warning, but the security risk is no longer there for paramiko (for other apps, it's a different story).
I don't know what has changed in the meanwhile but last backup that ran produced the following output: /usr/lib/python2.6/site-packages/Crypto/Util/randpool.py:40: RandomPool_DeprecationWarning: This application uses RandomPool, which is BROKEN in older releases. See http://www.pycrypto.org/randpool-broken RandomPool_DeprecationWarning) Traceback (most recent call last): File "/usr/bin/fwbackups-run", line 97, in <module> prefs = config.PrefsConf(create=True) File "/usr/lib/python2.6/site-packages/fwbackups/config.py", line 677, in __init__ self.__import() File "/usr/lib/python2.6/site-packages/fwbackups/config.py", line 817, in __import cron.write(crontabLines) File "/usr/lib/python2.6/site-packages/fwbackups/cron.py", line 224, in write raise CronError(_('Could not write new crontab:\n%(a)s%(b)s') % {'a': stdout, 'b': stderr}) fwbackups.cron.CronError: 'Could not write new crontab:\nno crontab for root - using an empty one\n python: can\'t open file \'/usr/bin/cronwriter.py\': [Errno 2] No such file or directory\n crontab: "python /usr/bin/cronwriter.py" exited with status 2\n' I am not very glad with this. Things seem to get worse instead of better.
That's a bug in fwbackups rather than paramiko. Looks like it's been fixed as well: https://bugzilla.redhat.com/show_bug.cgi?id=664077
Paramiko documents launchpad as the place for bugs and github as the place for code. However, this issue is opened on both without Robey Pointer (upstream maintainer) having responded: https://bugs.launchpad.net/paramiko/+bug/271791 https://github.com/robey/paramiko/issues#issue/1 There's a patch/pull request to solve this that was created in September: http://github.com/garyvdm/paramiko https://github.com/robey/paramiko/pull/8 We probably want to pull this for our package and probably should start talking to the other distributions about coming up with a team of people to take over maintainance (Robey Pointer said he was moving to github because he didn't use paramiko (at least the python version) anymore and wanted other people to be able to take over).
python-paramiko-1.7.6-3.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/python-paramiko-1.7.6-3.fc14
python-paramiko-1.7.6-3.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/python-paramiko-1.7.6-3.fc13
Eddie, if you could test that update and verify that it gets rid of the deprecation warning I'd be much appreciative. Bodhi should let us know when it is pushed to the testing repo or you could download it directly from koji (by following the links on the update page).
I have tested it running: [root@ls2ka ~]# fwbackups-run Maandelijks Jan 05 17:25:22 :: INFO : Starting automatic backup operation of set `Maandelijks' Jan 05 17:25:25 :: INFO : Using tar.gz: Must backup all paths at once - Progress notification will be disabled. Jan 05 17:30:08 :: INFO : Finished automatic backup operation of set 'Maandelijks' I did not see any errors. Looks like it is solved and the update can be forwarded to stable. Thank you very much. Regards, Eddie.
python-paramiko-1.7.6-3.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update python-paramiko'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/python-paramiko-1.7.6-3.fc14
python-paramiko-1.7.6-3.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
python-paramiko-1.7.6-3.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.