Ever since a recent patch to our Amazon instances we’ve been getting this warning when running Ansible:
PowmInsecureWarning: Not using mpz_powm_sec. You should rebuild using libgmp >= 5 to avoid timing attack vulnerability.
In researching this I came across https://github.com/ansible/ansible/issues/276 where a number of people have reportedly just commented the warning out of /usr/lib64/python2.6/site-packages/Crypto/Util/number.py and gone on their merry way. Personally I don’t like this approach since you’re just hiding the issue and not actually addressing it in any way.
In doing a little more research and testing I found that if I comment out the following block from ansible/lib/ansible/runner/init.py:
HAS_ATFORK=True
try:
from Crypto.Random import atfork
except ImportError:
HAS_ATFORK=False
And just replace this block with “HAS_ATFORK=False”, then the warning also goes away. What other side effects will this cause in Ansible if we patch it this way? We’d much rather patch the application and deal with side effects rather than patch system libraries in a way that just hides the warning. Obviously upgrading libgmp would be the best solution, but we don’t have the cycles to start building & deploying our own system libraries right now…
-Bruce
I disagree with the “in any way” statement.
We are using the atfork when we are can, on platforms where it is supported.
Your issue is that you have a version of paramiko that is too old, but it still does support atfork, so you are getting a warning.
Can I ask what OS you are using?
Unless it’s EL 5/6 where there is no ControlPersist, it’s almost always better to use “-c ssh”.
(And if you are on EL 5/6 and would like to get some nice speed, fireball is a good choice – in 1.4, fireball will soon no longer require 0mq as we were not getting any mileage out of it, just a basic socket server, but still using keyczar for encryption features on the shared ephemeral keys)
We’re not using paramiko. We’re using OpenSSH 5.9p1, with the following in our ansible config file:
[ssh_connection]
ssh_args=-o StrictHostKeyChecking=no -o PasswordAuthentication=no -o ControlMaster=auto -o ControlPersist=60s -o ControlPath=/tmp/ansible-ssh-%h-%p-%r
This is on an Amazon linux system, which is based on EL5.
-Bruce
You’re not using it, but the paramiko library is still being imported by the code, so it’s triggering that warning.
Yes, so I’m open to making the code import paramiko only when used seeing SSH is the default on most platforms, and still keeping the packaging dep.
Let’s make it so.
I recently upgraded a control server to ansible 1.5.x and started getting these messages. The server where we have to run ansible is RHEL 6.x but it seems that the newest version of gmp available from RH is still only 4.3. (I suspect that python is using libgmp dynamically rather than statically linking it…)
The warning shows up on every single ansible run and spams us with email from some ansible jobs that launch from cron. I think I’m going to comment out the atfork block on our system just because this is so annoying - is there a better approach for RHEL6? Any way to suppress the warning or fix the issue without installing packages outside the standard repos?
-Jeremy
Should have search issues on github before posting to the list. Looks like I’m hitting https://github.com/ansible/ansible/issues/6941 exactly.
For posterity (anyone else who searches the list before looking on github), it looks like commenting out a few lines in /usr/lib64/python2.6/site-packages/pycrypto-2.6.1-py2.6-linux-x86_64.egg/Crypto/Util/number.py is the preferred workaround.
FYI, Bruce’s workaround (disabling atfork) didn’t work for me anyway with ansible 1.5.3.
-Jeremy
Jeremy, I’ve merged in a patch to address this (https://github.com/ansible/ansible/commit/4cadcccc488fd12cb9d765cbcf5b2781072dc712), which essentially catches the warning and prints a nicely formatted warning to stderr. This error is also only printed once, so the verbose output from the original warning doesn’t show up for every host in the list.
Let us know if you have any further questions about this.
Thanks!
Nice - I knew I wasn’t the only person bothered by this. One thought - as long as there’s a block in init to specifically catch PowmInsecureWarning, it would be nice if there were a way to just suppress the output. I’d prefer not to redirect stderr from my cron jobs just in case some other error message pops up. Ideally I could do something like “export
PowmInsecureWarning=ignore” to suppress only this message.
-J
The current code does in fact say how to resolve the warning.
The trouble is Michael it’s not an easy resolution for many people. RHEL6 is probably very widely used, so we’re now getting into ‘dependency hell’ territory. Upgrading libgmp just isn’t practical.
If the problem isn’t that severe, and the error message can be suppressed, I’d like to be able to suppress it altogether too. It’ll just generate questions that don’t have an easy answer.
Mark, our main concern was not hiding a warning pertaining to a security issue, even if there was no current fix available. In order to find some middle ground, we’ve gone ahead and added a new configuration option: system_warnings. In 1.6, just set “system_warnings = False” in your ansible.cfg and it will suppress these warning messages.
Thanks!
Hello James,
Just tested, and that works a treat 
Thanks for looking out for all of us caught on old OS versions with no choice 
Cheers,
–Mark
Hello James,
Should a directory local ansible.cfg propagate to child directories? Only, I’ve just noticed system_warnings doesn’t appear to…
https://gist.github.com/phips/443bb40ebeaefc3c654d
Is that expected behaviour? Because I really like shipping directory specific ansible.cfg files - handy in given repository. But this means the pycrypto error rears its ugly head as soon as I drop into a child directory.
Cheers,
Mark
“Should a directory local ansible.cfg propagate to child directories”
Nope. We’re not going to climp up the directory stack until we find an ansible.cfg as that would be a bit cryptic and surprising to most people.
Stick it in your ~/.ansible.cfg or /etc/ansible/ansible and you should be good to go, otherwise set environment vars.
Roger that. Thanks for the clarification.