(Oh, btw, Kevin: sorry, I didn't report back to you to that funny bug. I couldn't reproduce it anymore.)
Hi, everybody! We are nearing the first milestone of my project and, full of pride, I showed my project director all the cool stuff I built with Mozart. I didn't fail to praise how incredibly easy the distribution system works, how simple it was to let prospective computation servers look for their master using Discovery and the like. He was very pleased. And then he asked about security. "Ah, well. Yes. There's something like an SSL patch for the Mozart interfaces, but it's not EXACTLY secure." I admitted, quoting what I had read on the project page. "So the system currently opens several ports to communicate with the other machines - and everything is going on unencrypted?" - "Yepp." And then his face turned green. Well. Not literally. We already considered IPSec as an option to secure what Oz can't anyway. But the crucial question is: can we do better? (Well, helping you guys with the SSL patch for Oz would actually be an option, but aside from that?) Is there someway to waterproof the connections between different Oz engines? Do you guys have similiar problems on your projects and how do you solve them? Is there any way to restrict certain communications (either from the distribution subsystem or the Discovery-thingy) to certain network interfaces? Thanks for your answers and have a nice weekend, Jens (who'll be on vacation next week, so don't be upset if I don't answer back right away...) -- Jens Grabarske (Research), DFN-CERT Services GmbH https://www.dfn-cert.de, +49 40 808077-621 / +49 40 808077-555 (Hotline) _________________________________________________________________________________ mozart-users mailing list [email protected] http://www.mozart-oz.org/mailman/listinfo/mozart-users
