Ben> Also, curious to know - what about out-of-band verifiers? So, for
Ben> example, I verify something on my PC, sign it as verified, then run it
Ben> on a Palm, with no verification?
My understanding was that there is a new kind of "split verification", where a pre-verifier (or the compiler itself) emits type tables as attributes in the bytecode.
I believe it's known as "Proof Carrying Code" in the literature. The compiler provides a "proof" that the code is "good", and then the JVM merely has to verify the proof, rather than constructing it from scratch.
That wasn't the relationship I had in mind, though its also interesting.
Essentially there's a reliance relationship[1] between the interpreter and the verifier. The interpreter relies on the verifier having done its job - the usual model is that the confidence that this has happened is caused by them both running in the same executable, and the code path being such that the verifier is run first.
What I'm suggesting is that you can have other relationships that generate the same confidence - such as an external verifier that signifies that it has done its job by signing the bytecode.
Cheers,
Ben.
[1] By this I mean what is often called a "trust relationship" - but I prefer to frame these in terms of reliance, trust being a rather woolly and emotionally loaded term.
-- http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
