> We've talked about the possibility of supervisor-mode blocks > in the past. > > I think the better possibility would be to have a optional BeanShell > enhanced Kernel.
<thinking out loud> I suppose I see the ease-of-writing benefits of thinking that way, but I'd have thought that the kernel metaphor would point towards having a supervisor-mode entity which Beanshell(s) could predictably use from user-mode. As much as I like Beanshell, I don't know that there aren't other usage scenarios that would suffer from it being anointed as the Way To Do That. I admit that following that line of reasoning to its logical end leads to more os-like things such as permissions and locking, but once there's interactive access to the resources under management, it's only a matter of time until two scripts collide. Or one script and a block that assumes things it shouldn't. </thinking out loud> Now that I've scared myself... > >As an aside, the reason I'm looking inside Phoenix at the > moment is to > >harden it for use outside of a protected server environment. To ward > >off malicious code, I'd like it to distribute Phoenix and my > app as a > >set of signed jars, and modify Phoenix to verify the jars before > >loading them. I've been using the Certificate Authority at > >http://ejbca.sourceforge.net/ to pretty good effect so far. > If anyone > >has walked this road before and wants to warn me about pitfalls or > >point me at useful resources, feel free. > > > > > V cool. Is your effort public or proprietory? Public, if it seems useful and practical. It has a pretty large list of dependencies and possible setup scenarios. Perhaps worse, there are a bunch of ways to set all the parts up and have them work but nonetheless have effectively zero added security (or even harming it) due to things outside the scope of the software. It seems to open up a Pandora's box of maintaining security-related HOWTOs that I'm not sure I'm qualified to do. I really want to at least return the gift to the Avalon community. If there is a way to carve that part off, I will. Making non-verified mode work alongside verified mode might be tricky. Making security a parameter pretty thoroughly defeats my aims <grin>. However, obliging all users to have a certificate verification path on startup (or even the knowledge of what a certificate verification path _is_) seems to go overboard the other way. I can say that the idea is under active consideration with a large predisposition to return code to Avalon, and the determining factor will almost certainly be the ability to put time into the dual-mode code issue over and above the time required to get the base functionality working. Any input/cajoling/devil's advocacy is welcomed. Jason -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
