Bug 1103566

Note -- it's not erroring out, just a warning.

Is there an updated gmp available in RHEL/EPEL to build against?

mpz_powm_sec was added in gmp5, so not for RHEL 6 unless it's decided to add it there as an additional ABI.

So, infra  sig, you own this package now.  I see several ways to proceed.

* Decide that the version of gmp isn't something we control and therefore close this as CANTFIX.  I've looked at the code and the warning actually means that python-crypto is not going to use gmp because of timing attacks.  It instead falls back on "slowmath" -- implementations of isPrime() and getStrongPrime() in pure python instead of in C.  So python-crypto2.6 is not insecure on RHEL6 - it simply is slower than it is on a distro which has a newer gmp available.  The drawback to doing nothing is that users see the warning about a "vulnerability" and think that their code is insecure because of the old gmp.

* Patch the warning out of the code because of the above analysis.  This package is primarily here for ansible vault in epel6.  The crypto routines are "fast enough" for ansible vault's purposes and most end users aren't going to read the warning and then compile their own gmp and python-crypto2.6.  Therefore, don't scare the users.  The drawback is if someone is evaluating python-crypto2.6 (or ansible-vault in a non-standard workload) and decides that it is too slow, not knowing that it's because of the gmp version on their OS that's causing it.

* Patch the warning to be more clear.  Something like:

    _warn("mpz_powm_sec in libgmp < 5 is vulnerable to timing attacks.  Using non-vulnerable pure-python fallback.  Recompile pycrypto against libgmp >= 5 to use faster routines.",  PowmInsecureWarning)

* Create a gmp forward compat package for EPEL6 and link against this.  It looks like the SONAME of the current Fedora package is different than that of the RHEL6 gmp so that portion is possible.  The package also contains a libgmpxx library which has not changed sonames.  This support library is only needed for building programs which use a C++ compiler to link to gmp.  We could place it in a different directory or omit it.  The header files for gmp are placed directly into /usr/include.  We'd need to place those into a versioned subdirectory and then patch build files to look in that subdirectory for header files.

* Patch the code to use fastmath with or without a warning.  The primary purpose of this forward compat library is to support ansible-vault.  In standard command line usage, the user will have access to any vault files that are present.  Therefore, they can simply copy the files to their own host to attack rather than relying on a timing attack on our systems to give them information about how close their attempted password is to the password used to encrypt the files.  I do not advise this option as we don't know who else might be using python-crypto2.6 on their own home-built applications where a timing attack would be important.

If this was still my package I'd probably patch the warning to be more clear unless someone else decided to build and maintain a forward compat libgmp in EPEL6.

I am completely happy to adjust the warning to be more clear. 

Hopefully also upstream would take a PR to do so in the next release? (It should apply anywhere I would think).

Made an upstream Pull Request: https://github.com/dlitz/pycrypto/pull/111

Will attach patch here.

Created attachment 974672 [details]
Clarify warning message about older version of libgmp

python-crypto2.6-2.6.1-2.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/python-crypto2.6-2.6.1-2.el6

I took another look at this today and found that I was wrong about precisely when the fallback code is invoked.  It looks like the fallback occurs when the C extension is unable to be loaded.  If the C extension is importable the code just will use it even if libgmp does not provide the secure function.

The package I've just pushed removes the _fastmath C extension so that the code will properly fallback on the slower but non-vulnerable python code.  Please test that it works.

Package python-crypto2.6-2.6.1-2.el6:
* should fix your issue,
* was pushed to the Fedora EPEL 6 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing python-crypto2.6-2.6.1-2.el6'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0740/python-crypto2.6-2.6.1-2.el6
then log in and leave karma (feedback).

python-crypto2.6-2.6.1-2.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.