No python Crypto Random in EL6

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/08/2013 06:49 PM, Orion Poplawski wrote:
> On 05/08/2013 03:54 PM, Pádraig Brady wrote:
>> On 05/08/2013 10:22 PM, Orion Poplawski wrote:
>>> So, one of my python packages that I'd like to see in EPEL6 
>>> (StarCluster) requires python-ssh.  python-ssh does not build
>>> on EL6 because the python-crypto in RHEL6 (2.0) is too old and
>>> doesn't provide Crypto/Random (see also 
>>> https://bugzilla.redhat.com/show_bug.cgi?id=908475).
>>> 
>>> I'm wondering what else might be done to get around this.
>>> Some options may be:
>>> 
>>> - Package up Crypto/Random somehow - port python-ssh to some
>>> other random number generator
>>> 
>>> Any other ideas?  Suggestions welcome.
>> 
>> I added a workaround patch for that in openstack-glance: 
>> http://pkgs.fedoraproject.org/cgit/openstack-glance.git/plain/crypto.random.patch?h=el6
>>
>>
>>
>> 
thanks,
>> Pádraig.
> 
> Thanks for that suggestion.  Here is my proposed patch for
> python-ssh then. Comments welcome.
> 
> Silas -
> 
> I can commit this to the el6 branch if you'd like.  Or I could
> commit to master and merge to el6 depending on how you track spec
> files across the branches.  Or perhaps you want to take care of
> it?
> 

/dev/urandom is not cryptographically sound. From the manpage:

A read from the /dev/urandom device will not block waiting for more
entropy.  As a  result, if  there  is not sufficient entropy in the
entropy pool, the returned values are theoretically vulnerable to a
cryptographic attack on the algorithms used by the driver.  Knowledge
of  how to do this is not available in the current unclassified
literature, but it is theoretically possible that such an attack may
exist.  If this is a concern  in  your  application, use /dev/random
instead.


As such, I highly recommend that you use os.random() instead. Yes,
this may result in blocking behavior, but since python-ssh is a
crypto-specific library, I think you need to ensure that it's truly
secure by default. I'd suggest adding a blocking/nonblocking flag to
the call, but I realize you're trying to stick with an identical API
interface to the original Crypto/Random.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlGLhuUACgkQeiVVYja6o6MJiACfQDwXe/s0JeLQYb4Ac5RVLQ5B
BZsAoJmVsFE+q+fgXe+zDQfDyrwvU0qb
=1INm
-----END PGP SIGNATURE-----