avalon-apps-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason" <ja...@shadowy.org>
Subject RE: BeanShell in Phoenix [ was JCrontab 1.0RC ]
Date Sun, 26 May 2002 15:09:30 GMT
> 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

Any input/cajoling/devil's advocacy is welcomed.


To unsubscribe, e-mail:   <mailto:avalon-apps-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-apps-dev-help@jakarta.apache.org>

View raw message