[e-lang] Joe-E 2.0 Release

[Adrian Mettler]

Thanks for the feedback.  In the current design, things are a pain when 
there are multiple projects with Joe-E code, as the verifier is not 
aware that the other projects are Joe-E verified.  I'm interested in 
improving this, both in the long term and implementing some workarounds 
for the short term -- it should be easier than your experience.  (I 
recently grabbed the waterken release to work on implementing the needed 
taming policy and encountered the same problems, and started 
implementing prefs in the verifier to make things work more smoothly, as 
it seemed to be even more of a problem then missing stuff in the safej 
decisions.)

At the moment, the verifer autogenerates .safej and Policy files, but 
this is not always necessary.  The safej files may be useful if the 
project will be used as a library (particularly a binary library).  The 
Policy file can be helpful if the project will be run as a stand-alone 
application and uses reflection on classes defined in the project. 
Neither are necessary if one is using a Policy file based on 
distinguishing trusted/verified code (for which all methods are enabled) 
by its classloader.  Ideally, there would be some way to tell when these 
files are needed or useful, but in the short term I can make a pref to 
toggle each of these on a per-project basis.  I can also have an option 
to generate a Policy file that implements the prior classloader-checking 
behavior to avoid the need for explicit taming info for non-library classes.

Another goal is to make the verifier aware of Joe-E code in other 
projects, making it easier to handle multiple-project applications. 
Previous versions had a hack of assuming that all source code in the 
workspace was safe to call, whereas all JARs had to be tamed, but this 
isn't a reliable distinction.  One could have legacy classes open as a 
source project, or Joe-E code included from a JAR.  The simplest 
approach to unify this was to require safej for everything (except, by 
technical necessity, verified source in the same project); but in the 
current implementation, I see that this is a real pain.  There are a 
number of ways I see to improve this:
(1) add a pref to restore the previous behavior of trusting all source.
     this is not a full solution, as not all source is trusted.  It also
     may make compile-time taming policy differ from runtime taming
     policy.  But it might be the easiest to implement temporarily
(2) recognize Joe-E code in other projects, the same way as Joe-E code
     in the same project, and allow it to be used.  This can potentially
     cause runtime and compile-time policy to differ, unless all Joe-E
     code from such projects is used in creating Policy.java.  Either
     way, I think that this is preferable to (1), as non-Joe-E stuff
     won't ever get treated as safe for no good reason.  Unfortunately,
     it still makes it a pain to use non-Joe-E code (which must still be
     added to the taming database).
(3) read the taming directory of other projects and use their safej in
     addition to the common safej configured in the preferences.
     The taming folder for a project would contain both autogenerated
     safej for Joe-E classes and manual or partially-automated safej
     for non-Joe-E classes in the project.  The safejs in a project would
     then be used for static taming enforcement and added to the Policy
     file in other projects that depend on that project.  This has the
     advantage compared to (2) of allowing use of source marked as
     non-Joe-E without requiring its classes to be added to the global
     taming database. The disadvantage is that it means that the safej
     files must be generated even if otherwise not needed, unless
     combined with option (2) in some way.

I'll see if I can implement (2) soon so you don't have to be dealing 
with safej for the multiple Joe-E projects in Waterken.

-Adrian


Tyler Close wrote:
> If I have multiple Eclipse projects that should be Joe-E verified and
> where some are dependencies of others; how do I set up the new taming
> infrastructure so that the Joe-E verifier does not complain about
> types in one Joe-E verified project being used in a separate Joe-E
> verified project? For example, currently I am getting Joe-E errors for
> the web_send project, which depends on the ref_send project of the
> Waterken server. How do I make these go away? When the Joe-E verifier
> runs on the ref_send project, it spits safej files into
> ref_send/taming; as well as dropping a Policy.java at
> ref_send/src/org/joe_e/taming/Policy.java. My Joe-E preferences page
> points at joe_e/taming where the safej files from the Joe-E
> distribution reside. The Joe-E verifier does similarly for the
> web_send project, spewing files into the web_send project directory.
> 
> Getting up and running with the new taming infrastructure in the Joe-E
> verifier has been a trial for me. This business of generating taming
> files for Joe-E verified code seems like a poor design to me.
> 
> --Tyler
>