Re: Joe-E 2.0 Release

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.

--Tyler

On Fri, Mar 7, 2008 at 8:08 PM, Adrian Mettler <[email protected]> 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
>  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
>  >
>
>
> _______________________________________________
>  e-lang mailing list
>  [email protected]
>  http://www.eros-os.org/mailman/listinfo/e-lang
>



-- 
Use web-keys for RESTful access-control:
http://waterken.sourceforge.net/

Name your trusted sites to distinguish them from phishing sites.
https://addons.mozilla.org/firefox/957/