On 10/05/2010 03:48 PM, Dennis Reedy wrote:
Just curious here, what if the decision was that you can only load
classes locally? That in order to get your classes you had to first
download the jars from a (trusted) server (perhaps even prompting the
user to accept the download?). You would verify the authenticity of
those jars before creating a classloader to load the required
classes. If you already have the jars (locally) necessary, why
download them again?
That would be my preferred way of security, matching practices already
there. Signed jars, downloaded with webstart, and communicating over jini.
Consider you already have the service's interface (and any other
supporting classes) in your classpath to begin with (which is loaded
locally), why not provision the remote service's proxy jars first
before connecting to the service? Appropriate handshaking happens to
connect to the remote service of course, but do you take the dynamic
insecure class loading out of the equation this way?
Yep.
But i got the feeling that others within the river community still want
to maintain the same 'code agility', as deployment on a lan.
Gr. Sim
