Awesome. How many people have reviewed it for flaws? How many people have reviewed OpenSSH?

How many people have reviewed Paramiko? In particular, how about that ecdsa patch[1] to Paramiko that you'll need to be accessing modern Ubuntu or Fedora (and before long, RHEL/CentOS). What about the python-ecdsa[2] (that paramiko's provisional support for modern Fedora and Ubuntu's default configs is based on)? This entry from its README seems pretty frightening:

    This library does not protect against timing attacks. 
    Do not allow attackers to measure how long it takes you 
    to generate a keypair or sign a message. This library
    depends upon a strong source of random numbers. Do not
    use it on a system where os.urandom() is weak.

I'm not saying Paramiko (or its patch sets) are insecure, just pointing out that the same arguments can be made against the libraries and code that Ansible is based on.

[1] - https://github.com/paramiko/paramiko/pull/152

[2] - https://github.com/warner/python-ecdsa

> Do not use it on a system where os.urandom() is weak.

So, don't use it in the cloud? [1]

1. http://harvey.binghamton.edu/~ychen/chen-kerrigan.pdf

After finishing the Cousera crypto course, I did a quick review of their approach and found 2 issues which completely broke their authentication protocol (https://github.com/saltstack/salt/issues/2239 & https://github.com/saltstack/salt/issues/2916).

Which they seemed to fix pretty quickly, mainly by migrating to keyczar.

Which is one of the reasons I like them as much as I do. I can watch the iterations, they work hard on their product are committed to open source, and release regularly and often.

The other big win for me is I can read their code, I understand python & have a number of items I'll be able to contribute to upstream that will help others use the product.

If it's a concern, just lock it up behind iptables. Only let your master talk to your minions and your minions can only talk to your master.

I'm not telling you it's malpractice to use it that way, but we wouldn't.

Why?

I'm not tptacek, but note that IP addresses are not exactly cryptographically secured. If you only restrict access by IP address, you tend to lose your whole intranet as soon as one host falls.

(Then again, that's how it usually goes anyway.)

Maybe they should hire you to review it for security flaws?

At one point in time ZeroMQ was not hardened and direct exposure to the internet wasn't a good thing. It appears they have fixed it, but it hasn't proved it self so the perception lingers on.

http://www.zeromq.org/area:faq#toc8

ZeroMQ used to be full of assert() calls that would fail on bad data and crash whatever was listening. It was trivially easy to cause problems for someone's ZMQ socket-listening service. It's been fixed, but the perception lingers on.

A few years back it was common practice NOT to expose ZeroMQ to the wide open internet as it was built for that. I think they says it OK now, but its left a bitter sense for some of us.