Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Sat, 12 Aug 2006 17:49:10 -0700
To: harmony-dev@incubator.apache.org
Subject: Re: [general] compatibility packages
Message-ID: <20060813004910.GA16820@pogo.kaffe.org>
References: <20060812124255.GA23610@pogo.kaffe.org>
 <D92197D0A6547B44A1567814F851FA6827A680@LEMBU.sumatrasoftware.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <D92197D0A6547B44A1567814F851FA6827A680@LEMBU.sumatrasoftware.com>
User-Agent: Mutt/1.3.28i
From: Dalibor Topic <robilad@kaffe.org>

On Sat, Aug 12, 2006 at 08:50:42PM +0200, Jeroen Frijters wrote:
> Dalibor Topic wrote:
> > So if I can't run the sun.misc.Unsafe remote exploit on 
> > Harmony it is a failure? ;)
> 
> You keep referring to this, but IMO this is a mischaracterization of the
> exploit. The exploit used a bug in JavaScript that allowed access to the
> sun.* package, that was the real problem not the sun.misc.Unsafe class.
> 

sun.misc.Unsafe was used to replace the SecurityManager's security field
with null, which allowed the code to download a payload and Runtime.exec
it. It's a nifty little exploit, if you google around you should be able
to find the disassembled code.

First part of the problem was the JavaScript bridge, which allowed
access to sun.* code, and the second part was sun.misc.Unsafe, which
allows kicking the legs under the Java security mechanism in three lines
of pure Java code, once you get access to it.

The exploit only works on VMs with a sun.misc.Unsafe class, obviously.
Microsoft's JVM is not affected.

I keep bringing it up because it is a nice example for what I am saying:
copying Sun-specific classes without need is a liability, rather than an
advantage.

> You also keep hammering on CharToByteConverter as an example of bad code
> that should trivially be fixed (and it obviously should, if possible,
> but it's not always that easy), but there is also code out there that
> uses sun.* classes to do things that are impossible to do with the
> documented APIs. How would you fix those?

If someone deliberately writes VM-specific code, you can't always fix
it. There may be a good reason to do so, for example if you are doing
research on Sun's implementation and hook into their VM using their
internal interfaces. There is nothing to fix in such a case, the code
works as designed. We'll never be able to perfectly run all those 
intertwined RMI extensions that work by hooking themselves deep into 
the interna of Sun's implementation, but that's so by deliberate design
of the code: the authors wanted to take advantage of the interna of
Sun's implementation. Is that a problem for anyone? I don't think it is.

But there is no good reason in 2006 to use a Sun-internal Base64
implementation, or the sun.io APIs, afaik. The only reason why we care
about sun.misc.Unsafe is Doug Lea's code, which seems like it can be 
refactored to offer a cleaner interface to the underlying VM, as I 
explained. I am not aware of any other potentially useful code that uses
sun.misc.Unsafe, but I'd appreciate pointers.

> BTW, that was a retorical question, because I already know your answer:
> that's rubbish software that won't work reliably on Sun's JRE anyway, so
> why should we support it?

That's by far not the whole story. My apologies if it came accross as
that simplistic. I'd say there are three categories:

a) Simple mistakes people make by copying
mistakes other people make. Base64, sun.io, etc.

b) Choices of convenience: Base64, sun.io, etc were here as long as
there were no better choices to get the job done. For most things, there
are now, afaict.

c) VM-implementation specific code: a lot of extensions to VMs and class
libraries fall into this category by design.

Can we accurately support c? I seriously doubt it.

Can we accurately support b? Maybe, but code in b) tends to rather 
quickly move into a) as more interfaces are standardized over time, which 
means duplicate code to maintain for less benefit.

Can we suport a? Maybe, but do the benefits outweigh the negative sides?

cheers,
dalibor topic

> However, I've spoken with Mark Reinhold about this issue and he told me
> that Sun sometimes reverts changes to sun.* classes because a customer
> complains that it broke their code. I asked him if they would be
> documenting these classes when they do this, but he said they wouldn't.
> So they seem to live in a dream world where on the one hand they want to
> discourage usage of sun.* and on the other hand continue to support it.
>
> Like compatibility in general this is a hard problem and we need to take
> a pragmatic approach and I really like the current plan of having an
> optional suncompat module.
> 
> Regards,
> Jeroen
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org