Well, ok, if you trust then other end then I think it's enough to just
authenticate all the pickles (say using hmac.py) without needing
something as heavyweight as SSL.
An interesting idea that hadn't crossed my mind yet. Pyro *does* already have connection authentication that uses md5 (and hmac since 3.5beta) with a shared secret, but after that, the communication is done in plaintext so to speak.
If you use SSL you need something like m2crypto since the SSL option in the socket module doesn't check certificates, IIRC.
I'm using m2crypto for this kind of SSL, yes. (sadly it has a bug in its API that is triggerd by the current Pyro version on some platforms like Linux).
In fact, this is the reason why I started this thread. I wanted to discover some possibilities to replace pickle by another thing, so that Pyro becomes 'safe' at the wire protocol level. But further discussion on the Pyro mailing list sort of made it clear that this is not desirable.
Why do you say it's not desirable? Don't competing protocols like RMI try to stay safe from malicious peers? Why should I not want to expose a Pyro service to the internet? It's a natural thing to want to do.
You should not want to expose a Pyro service to the internet because Python doesn't have Java's security model and sandboxing, that are used with RMI. Pyro has a few features that are very powerful but also require the use of intrinsic insecure Python code (namely, pickle, and marshal). Just look at the recent security advisory about the XMLRPC server that comes with Python.... it's much more primitive than Pyro is, but even that one was insecure.
I wouldn't put a Java RMI server or xyz CORBA server or whatever kind of unrestricted API open on the internet anyway. Am I rational or paranoid?
--Irmen -- http://mail.python.org/mailman/listinfo/python-list
