Paul Rubin wrote: > Dave Brueck <[EMAIL PROTECTED]> writes: > >>>What do you use for HTTPS? >> >>m2crypto (plus some patches to make asynchronous SSL do what we needed). > > > That seems to be a nice piece of code, but it's still at version 0.13;
Version numbers are fairly relative, though. In another project we're using some proprietary, closed source libraries (unrelated to crypto) that are version 3 and they seem buggier and less stable than m2crypto. And don't get me started on Microsoft products (we've been using DirectShow *9* in some stuff, and due to bugs in DirectShow we were completely and utterly screwed despite what the documentation said; things just didn't work as they should, and Microsoft has confirmed that it's a bug that will be fixed in some future release - so we had to backtrack, ripping out code that should work just fine, and take another stab at getting DirectShow to cooperate). Version NINE (supposedly). > if something goes wrong, are you sure you want to explain that you > were using beta-test software to protect your customers' production > financial transactions? lol - what? We're not doing any financial transactions with it (IOW - we evaluated m2crypto for what we needed to do, and it's a good fit - that we didn't evaluate it in terms of what we don't need it to do doesn't bother me). Having said that - I think we probably *would* use it for production financial transactions - but that's more a matter of closed vs. open source than Python vs not. Besides, do you really think that, if something went wrong, you'd in the end have some meeting where you explain to your customer that you were using beta software? Of course not - it just doesn't work that way. Either they won't care and will drop you because of the problem (regardless of the source) or they want some broad details. > There's also been some traffic on the > python-crypto list about Zope encountering memory leaks with it. Ok... so? I mean, if there's a memory leak, and it's hurting us, we have options: we can go look in the source code, we can make Zope reboot itself often, we can hire somebody to fix it, we can see if the author wants to give us a support contract, etc. Memory leaks aren't exactly unique to Python - according to bugs.sun.com, there are currently 382 *open* bugs related to memory leaks in the JDK alone. If you're using Java in your "huge, enterprise size app" and get bit by one of those bugs, and if you're not a big enough company to get some ridiculously-priced support contract from Sun, what are your options? Again, this seems more like an open-vs-closed source issue, but to me it's another reason why I'd feel uncomfortable using Java in mission critical work. -Dave -- http://mail.python.org/mailman/listinfo/python-list