www-community mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: WORA Considered Evil ;-)
Date Sat, 28 Jun 2003 19:06:49 GMT
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?


To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org

View raw message