Sim IJskes - QCG wrote:
On 10/04/2010 05:49 PM, Mike McGrady wrote:
I think that we need to decide what the requirements are? Anyone
else thinking this? NSA has a tee shirt saying, "We trust in trust".
Defining requirements is good. But an excercise determining if jini is
ready for the internet is also good. This excercise can consist of
discussion of pros and cons of keeping the existing code, or adding
code to it. By having arguments and counter arguments we can build an
(collective) instinctive feeling for the strength and weaknesses of jini.
I'm sure the original jini team had similar discussions, maybe not
over email, but more around a beer, or at the coffee machine. We need
to rebuild this team coherence.
Gr. Sim
BTW: i also do trust trust, and even i trust trust is trust.
Ok, my thoughts, the team that produced the Jini security infrastructure
were a smart bunch, we can utilise any provider we like, it's very
pluggable, fortunate are we. We're also very fortunate for the
brilliant security foundation in the JVM, Li didn't get to go all the
way like he wanted, but his team managed to make history.
The whole escaped reference security auditing problem in Java wouldn't
exist if Li's Guard Pattern was utilised for methods in all Java's
security sensitive classes.
If you read the Jini Davis project interviews on Artima between Bill
Venners and Bob Scheiffler, you soon realise that they knew Jini
Security wasn't quite finished.
I'm not saying don't change the code, or that it's perfect (anything
that's perfect is obsolete since it no longer changes, sorry can't
remember the author), I'm saying, hmm there are some issues, lets
investigate them.
Jini's model of trust is quite clever, it's a key component,
establishment of trust has been implemented, we have SSL and Kerberos
JERI Endpoint Client's for Unicast discovery, so the Registrar proxy
objects (in serialized form) coming down the wire are private, between
the client and the registrar. We have integrity, Jini verify's that the
CodeSource has the correct checksum, specified by the remote Registrar.
The catch, there's this short period, where we haven't authenticated the
Registrar, or verified the proxy, to do that we must ask the proxy for
it's bootstrap proxy (a piece of local code) required for
authentication. To authenticate, we must unmarshall the proxy.
When we unmarshall the proxy, we're exposed to a DOS attack, no loss of
private information, no real security hazard, just the irritation that
Jini Service based Software will be made up of both Services and Clients
and the DOS attack makes it brittle.
So I agree, trust is important.
To build team coherence, we must be prepared to listen and learn from
the old hands who volunteer information, building cases for arguments
just makes them fall silent. When someone puts forward an opposing
view, you don't have to take sides, it's better to just ask questions.
The reason that Jini wasn't a howling success like Java was not the
fault of the code, I just think the timing wasn't right, it wasn't
finished and has some areas we need to work on, we have people like
Peter Jones, Tim Blackman, Dennis Reedy, Gregg Wonderly, Michel Kleczek,
Chris Dolan, Zoltan Juhasz, Fred Oliver, Greg Trasuk, even Jim Waldo
occasionally, Jim Hurley and Brian Murphy, who know the issues and are
prepared to share their knowledge. (Sorry if I've forgotten anyone -
off the top of my head, no particular order) but we've also got our team
of regular committers, Jonathan, Patricia, Sim, Tom and myself.
It's important we examine the code, ask questions respectfully and learn
from each other. It is difficult working from opposite sides of the
world, we've got cultural differences, there's no body language to
assist, but I'm confident we can work it out.
Cheers,
Peter.
