Re: Joe-E 2.0 Release

Also, rather than have separate safej files, I recommend there just be
a Policy.java file in the Joe-E distribution that contains all the
Java taming decisions. If people want to add more taming decisions,
they edit the Policy.java file.

--Tyler

On Sat, Mar 8, 2008 at 7:35 AM, Tyler Close <[email protected]> wrote:
> 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/
>



-- 
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/