on 6/27/03 5:37 PM Steve Brewin wrote: >> - the chance of a JVM exploit. >> - potential exploits via native code in >> a JDBC driver. >> - the use of native code in matchers/mailets, >> e.g., the anti-virus matcher. >> --------------------------------------------------- >> - the use of third party matchers/mailets. >> - the use of user-defined scripting matchers/mailets >> - support for SOAP >> - one pipeline being extra busy or big >> performing lots of processing and/or >> handling large messages, should not >> deny service to other users. >> > > I remain unconvinced that all of the issues are potential security risks, > but as I tried to say in an earlier posting, its a matter of trust.
Many java programmers are used to think that being so abstract from metal, a java JVM is instrinsically more secure. It is true that the usual types of attack like buffer overflows just don't make any sense (unless they attack the native libraries underneath, but even that is hard) and that the JVM security model is very well designed (they choose security over performance and it's a choice that, IMO, paid well, .NET does the other way around and we'll see what happens) At the same time, imagine taking all sendmails of the world and substitute them with what James right now, how long would it take hack into it? I would suspect a few weeks. Yeah, it's a matter of trust and it's because of paranoia that trust is created because it's a catch-22 cycle: - sysadm are paranoid (irrationally so, so forget about changing that) - sysadm with big load and with a system that works, won't change it because of architectural elegance, you need functionality: they look at security, performance and ease of configuration/use (in that order) and 99% of them stop there - performance can be effectively measured, ease of configuration/use can be tried and appreciated (although irrationally as well, so be prepared to do stuff that *they* are used to, not stuff that you think they should be learning to do! this is the key to usability: adapt the system to users, not the other way around) but... - security cannot be measured, it's a matter of trust. I'll tell you a story: Apache JServ is still considered today one of the most solid, scalable and lightweight servlet engines on the market. So much so that Oracle still ships it in their AppServer. Well, we *never* were able to convince the Apache sysadms to install it on apache machines. Why? at the end, I think, it was lack of trust. On java, on java on freeBSD, on the load consumption, on the memory consumption, I can't really tell you what it was, but, reality is that it never happened. is there an *real* reason for that? I don't think so. but we are humans, we have feelings and we have fears. If you don't design a technical system taking ease of use and the users' fears into consideration, you are doomed to failure in aquiring a good and diverse community of users. Reading your post that dismiss the UNIX sysadm fears as a "think of the past", remind me of the discussion Pier and I had when we thought about the exact same thing of Brian's (for us, excessive) concerns on java. Today, after being involved in infrastructure@ for a while (just lurking, I'm not even close to be decent enough as a sysadm to help them), I can tell you that it's exactly this "get modern and stop the crap" approach that is hurting java and stopping it from becoming mainstream in main fields. I might be wrong, but I blame it on WORA. I'm really happy to hear Noel having a much more "down to earth" approach to the problems, it will give James much more chances of being appreciated by a much wider audience. And this was the reason why I started talking about this. You can argue all day about the technical reasons why those fears are unjustified, but fears are not objective: there are aereonautic engineers who are afraid of flying. From a purely rational point of view, it should be impossible, but it happens. Pier is a world-class java programmer and earned this merit by participating in writing some of the best java software available on the market. Still, and maybe because of this, he doesn't trust it as much as it trusts other software or, let's put it this way, doesn't trust the WORA-injected syndrome that everything should be run inside the JVM. I heard rumors that many of the Solaris engineers in Sun think exactly the same about java, but they are silenced by the company. Go figure. So, at the end, while I agree with you that some of those fears are technically hard to justify, the only objective part is that they exist. You can choose to ignore them, but in doing so, James will just never exit the "cool concept" stage it has been in since its creation. I believe there is critical mass for this project to exit that stage and enter the next phase where it really starts eroding marketshares of other mail servers, but the mindset of its developers must exit the 'go pure and screw their stupid fears' because it's not the right approach. Look: everybody on this planet hates sendmail, qmail users like the software very much but strongly dislike the fact there is no community around it, postfix is gaining momentum not because of technical excellence but because of its real open source nature. Combine technical and architectural excellence with an apache-style open development community and you have the potential to become one of the big players of this market. But as yourself: why this is not happening? Today, UNIX sysadm understand that java is not *that* unsafe, if you can run a those huge appservers without that many security problems. So, they will give you at least one chance of proving your point. So, IMO, the time has come for james to show what java can do for email. They are willing to make a step toward you, are you willing to make a step toward them? -- Stefano. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
