Re: Joe-E 2.0 Release

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

On Mon, Mar 3, 2008 at 6:31 PM, Tyler Close <[email protected]> wrote:
> OK, I assume the Joe-E verifier will get the opportunity to run even
>  though the project has Java level compile problems?
>
>  Could you provide a Policy.java class that maintains the behaviour of
>  prior Joe-E releases?
>
>  Thanks,
>  --Tyler
>
>
>
>  On 3/3/08, Adrian Mettler <[email protected]> wrote:
>  > The dependency on the missing class is as intended.
>  > org.joe_e.taming.Policy is the runtime taming information.  It is
>  > automatically generated by the verifier to include all the methods
>  > permitted in the safej files and all the methods defined by Joe-E code
>  > in the project being compiled.  An alternate approach would be to use a
>  > "standard" org.joe_e.taming.Policy that only includes taming decisions
>  > for library classes and uses classloader lookups to ensure that
>  > reflective access to new code is allowed; this is what is suggested to
>  > maintain the current behavior of waterken, so that new code can be
>  > verified and added in an open-ended way without needing to recompile
>  > org.joe_e.taming.Policy.
>  >
>  > -Adrian
>  >
>  > Tyler Close wrote:
>  > > The code in library-2.0.0.jar has a dependency on
>  > > org.joe_e.taming.Policy, but this class is not included in the jar. Is
>  > > this a mistake, or am I supposed to generate it somehow?
>  > >
>  > > --Tyler
>  > >
>  > > On Wed, Feb 20, 2008 at 3:05 PM, Adrian Mettler
>  > > <[email protected]> wrote:
>  > >> Joe-E 2.0 has been released, and is now a bona-fide open source project
>  > >>  with all the trappings (like public svn and an issue tracker).  Check it
>  > >>  out at
>  > >>
>  > >>  http://joe-e.googlecode.com
>  > >>
>  > >>  The eclipse update site for the verifier plug-in proper is now
>  > >>  http://eclipse.joe-e.org
>  > >>  which resides within the svn repository.  This will make it easier to
>  > >>  push out new releases, so they should be more up to date.
>  > >>
>  > >>  New verifier features include:
>  > >>  - support for safej format for specifying taming decisions
>  > >>  - validation of consistency of safej policies
>  > >>  - taming errors give explanation of why member was disabled, based on
>  > >>  safej comment
>  > >>  - ability to enable/disable verifier on a per-package basis
>  > >>  - auto-generation of safej and Policy files for runtime taming enforcement
>  > >>  - bug fixes
>  > >>
>  > >>  New library features include:
>  > >>  - real runtime taming enforcement
>  > >>  - builders for array classes
>  > >>  - documentation improvements
>  > >>
>  > >>  As always, feedback is welcome.
>  > >>  _______________________________________________
>  > >>  e-lang mailing list
>  > >>  [email protected]
>  > >>  http://www.eros-os.org/mailman/listinfo/e-lang
>  > >>
>  > >
>  > >
>  > >
>  >
>  > _______________________________________________
>  > 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/