2010/11/2 Mikael Helbo Kjær <[email protected]>: > I don't have an informed opinion on the python stuff, but I can't help but > having to ask about all of the claims about security and stability related > problems I've seen on the list recently. Does zmq have fundamental issues I > am unaware off? Or is it as I thought just immaturity?
As we use 0MQ for more demanding applications that stretch wider, we hit new problems. That's the reason for the discussion, it's a reflection of more people using 0MQ and pushing the envelope, not any inherent issues. 0MQ is not as such secure, any more than its underlying transports are secure. That is, you don't expect TCP to do encryption, and neither does 0MQ. However, 0MQ applications that carry data across the Internet _do_ need security and there's been quite a lot of talk on how to do this. The options seem to be: * Use a VPN (horrid, for most people except network admins who like this) * Use per-message encryption (as PyZMQ does but it leaves the question of key exchange unsolved) * Use TLS/SSL as a transport (seems cleanest but is incompatible with multicast and the notion of hops over devices) * Tunnel over a secure protocol, e.g. HTTPS (should be interesting, especially to make 0MQ accessible to web applications) Regarding stability, there are a mix of issues: * 0MQ historically used assertions to report errors which we're learning should be handled silently or with logging. * 0MQ hasn't been systematically 'hardened' in terms of how robust it is to bad input, and we have launched a competition[1] to harden it. Dhammika Pathirana is in the lead afair with 3 points. * 0MQ doesn't have a fully documented wire protocol so no-one has built interoperable stacks, which is usually the way we make sure protocols are robust. Blame me, I was supposed to write this up but haven't had time. * Historically, 0MQ was geared towards a more static and smaller network of nodes. With 2.0, we introduced messaging patterns and the product started to aim towards larger dynamic networks. But things like socket closure or handling hundreds of nodes starting up at once didn't work properly. These areas have now been made much more robust, mainly driven by real applications. * Like any developing product, new code is unstable. We're pushing the packaging towards a more traditional 'stable' vs 'unstable' model so that you can explicitly download the stable release or unstable release, or raw development version. Today there's still no 'unstable' release as such. Ironically this makes the product look less stable since more people use the development master than need to. Hope this helps. It's always useful to have the viewpoint of someone coming to the project, so thanks for speaking up. :) - Pieter Hintjens iMatix - www.imatix.com _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
