>>>>> "Bob" == Bob <[EMAIL PROTECTED]> writes:
Bob> While it's still in its initial stages, I would like to advocate for Bob> the importance of the Java 2 Security Model, and that it is Bob> implemented correctly. I wouldn't worry about this too much, I think it is implicit in the goal of having a complete implementation. It is true that the current free implementations don't really address this fully. We're looking at this as an important task for libgcj over the next year or so; at least, a few of us are trying to push a Mozilla plugin as an important app, which entails handling this. Bob> Implementation requires a "security stack", every layer of which must Bob> be gotten right: Thanks for the list. In addition to audits and the like, I really want to see comprehensive free test suites for all these components (some of these are notably missing at the moment). Bob> 1. Language specification (public/private, pointer safety, etc) This is usually handled by the core part of the VM. This is something I think we could share. Bob> 2. Bytecode verifier There's a (reasonably) pluggable verifier in gcj (the pluggable refactoring is on the gcjx branch). Bob> 5. Correct implementation of fine-grained permissions (which find Bob> themselves all over the Java library) Most of this is done in Classpath, but it could use an audit. Some of these checks are still missing in the divergent parts of libgcj. Bob> GCJ is fundametnally not appropriate for the Bob> implementation of Java security, due to its ahead-of-time machine code Bob> compilation model. With the new binary compatibility ABI, this is no longer true. We can do full checking with no trouble. We have even written the compiler to emit type assertion tables, to duplicate the runtime effects of verification (without the expense). I'm not trying to push gcj here, and this doesn't eliminate other reasons one might prefer JITting... I just wanted to avoid propagating inaccuracies. Tom
