[e-lang] Joe-E 2.0 Release
tyler.close at gmail.com
Sat Mar 8 10:35:06 EST 2008
I've got an alternate proposal for marking Joe-E code.
Java supports package annotations that are available at both compile
time and runtime. I suggest Joe-E define an annotation
org.joe_e.verified. To enable Joe-E verification of a package, the
programmer adds the standard package-info.java file with content:
@org.joe_e.verified package org.example.stuff;
The Policy class can then check that a reflected member is either
defined in a Joe-E verified package, or is enabled in the safej
database. The safej database then doesn't need to contain any
information about Joe-E verified code, only tamed Java code.
On Fri, Mar 7, 2008 at 8:08 PM, Adrian Mettler <amettler at cs.berkeley.edu> wrote:
> 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
> 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.
> 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
> e-lang mailing list
> e-lang at mail.eros-os.org
Use web-keys for RESTful access-control:
Name your trusted sites to distinguish them from phishing sites.
More information about the e-lang