Download by Platforms & Versions

Earlier versions of E have
been tested and run on MSWindows (95, 98 FE, NT, 2K), and Linux. It should
run on other UNIX platforms as well, given an adequate version of Java
and bash (see below). It should also run without problems on MSWindows
98 SE and on ME, but as far as we are aware, no one has tried this. If
you experience any problems, or have any other informative experiences,
please let me know, or report
a bug.

The Installing links below describe how to install, and run various
forms of the binary distribution. The Building links describe how
to build E from the source release. The Download links will download
each corresponding form of the release to your machine.

Highlights of this Version

As each of these issues are discussed in email or in the bug tracking
system, we will link the paragraphs below to the relevant roots.

MarcS' eDesk -- Visual POLA for Caplets

eDesk is a desktop and designed-to-be-secure(*) computing environment
built on the E platform, for the installation and running of caplets
-- capability-based applets/applications that run with only the authority
that has been explicitly given to them.

A secure computing architecture means little for its human users unless
its security principles are brought out to the user interface in an
intuitive, usable, and non-accident prone fashion. The key insight is,
once again, Norm's: "A capability combines designation with
authority."

Modern user interfaces are the result of billions of dollars of work
on the designation problem -- how to tell one thing, designated somehow,
to perform some operation of some other thing, also somehow designated.
As user interfaces have improved, they have also moved towards more
capability-like means of designation, as in the moves from names and
clipboards to drag-n-drop.

As with Miriam & Ping's Interaction
Design for End-User Security, the main "trick" of eDesk
is to bundle authorization in with these acts of designation. For example,
when a capEdit -- our text editor caplet -- requests a file to edit,
the file dialog box that pops up enables the user to conventionally
designate which file the caplet should edit, but in so doing, in the
same act, provides the caplet the authority to do this editing.

(*) eDesk won't really be secure until the "Taming Java"
work mentioned below is adequately complete.

Term Trees, for real this time

John McCarthy has said: "XML is just S-Expressions, only ten
times as verbose." This comparison, while critical of XML,
helps explain the source of its appeal -- for most of the computing
world, XML is the first S-Expression-like system they've seen. What
XML, S-Expressions, Antlr ASTs (abstract syntax trees), and Prolog Term
trees have in common is that they are notations (or surface syntaxes)
for "practically universal" trees of symbols. These trees
are "practically universal" in that many other forms of symbolic
data can be mapped into any of these trees.

The clearest and most compelling case is the Antlr AST -- these are
used to represent the result of parsing anything that can be parsed
according to a BNF grammar. This demonstrates that one such universal
data structures may have a great multitude of surface syntaxes.

Each of these S-Expression-like systems provide somewhat different
levels of syntactic overhead, provision for type specification, and
semantic clarity. For the purposes of E, a simple, clear semantics (to
enable quasi-literals and for security reasons) is required, and compatibility
with Antlr is highly desired.

Although the Antlr documentation also calls its ASTs S-Expressions,
and although the Antlr notation for writing them looks like S-Expressions,
semantically they are actually most similar to Prolog Term trees. Since
Antlr is the system we most desire to interoperate with, as of this
release we introduce E's Prolog-like Term trees, with conversions back
and forth to Antlr ASTs. We also adopt a Prolog-like surface syntax
for our Term trees, as that looks more familiar to the C syntactic tradition.
For example, the parsed form of E's

In an E Term, a functor is an identifier or a literal data element.
An identifier, like "assignExpr" above, serves the same role
as a does a tag name in XML. A literal data element is either a literal
character, integer, floating point number, or string, written the same
way, and meaning the same thing, as these literal data elements do in
E. (This is the same as they do in Java, except that integers are precision
unlimited, and floating point numbers are always double precision.)
A Term always consists of a functor and zero or more arguments.
These arguments are its children, which transitively always form a finite
tree. The leaves of the tree are simply Terms with no arguments. For
Terms with no arguments, the "()" is optional.

Taming the Java API with *.safej Files

One of the more controversial aspects of E's history is our decision
to build on the Java platform, among other things, in order to inherit
its great wealth of libraries. The biggest problem with this plan is
that the Java libraries were not designed according to capability discipline
or style. The good news is that good modular object code is often very
close to being good capability code, and much of the Java API that we
wished to inherit was indeed close in this sense. So, in most cases,
closing the remaining gap was more a matter of taming (or domesticating,
or housebreaking) rather than wrapping or replacing with a redesign.

Historically and still, this taming is done by hard coding within the
E implementation. (Actually, it is partly data driven, by only by hard
coded tables scattered through the E implementation.) This has worked
for the scale of taming we have so far made implicitly available to
*.emaker and *.caplet files, but is woefully inadequate for the actual
needs of caplets. Caplets are generally interactive, and so need access
to a substantial portion of the AWT and Swing APIs. These are too large
for taming by hard coding.

Instead, MarcS wrote a tool, the capAnalyzer (not yet released,
but expect it soon), with which he interactively examined the relevant
portions of the AWT and Swing APIs. The results of the analysis of each
class are present, though unused, in this delta release as a Term tree
in a *.safej file available in the e.jar as a resource:

Some parts of this are currently placeholders for expected taming info
yet to come -- the byproxy, selfless, byconstruction,
and persistent attributes, that will say whether instances
of the class should be considered by E to have these properties. (Note
that byconstruction and persistent both will
require the class to be Serializable. byproxy
excludes selfless or byconstruction.) "true"
and "false" should not have quotes around them (my mistake).
If a comment is present, it isn't for the purpose of a Javadoc comment
on the method or class itself -- which we also perhaps need to capture
in a resource, for use in interactive help -- but rather a comment explaining
this taming decision, also perhaps useful in interactive help as an
addendum to the Javadoc comment. Such a comment, if present, would be
shown as a "comment" terms with a string argument.

The most important field is the "safe" attribute.
This says whether the class itself should be made implicitly importable
by using the universally accessible <import:...>
expression. If not, then the class is still importable by <unsafe:...>,
which is available only in the privileged scope. The API of a class
and its instances are to be tamed by the above description regardless
of how it was imported.

This delta release does not yet process these *.safej files
at all. It still does its taming only by the far more conservative manual
hard coding. As a result, the caplet environment contains unsafe scaffolding
code -- code which grants to a caplet instance the ability to import
untamed AWT and Swing classes. Until this scaffolding code is removed,
we can only say that the caplet environment was architected to be secure,
not that it is actually secure. We include the *.safej files
in this release anyway so that y'all can have a look and double check
our taming decisions before we make them operational. If you find any
taming decision to even be puzzling, please let us know.

Variants and Subsets of E

A complete E system is persistent,
distributed, and capability-secure both within and between processes.
Incomplete variants of E
are tagged by which of these features are left out.

Feature

Prefix if
feature is absent

What it stands for

Persistent

tl-

Time-Local

Distributed

sl-

Space-Local

Local
capability security

otc-

Only-Trusted-Code

Distributed
capability security

daffE

Distributed Application FrameworkForsaking Encryption

A non-persistent E is called
time-local since an object only exist as long as its hosting process
does. A non-distributed E
is called space-local if an object and all references to it only
exist within its hosting process.

Eby definition provides
distributed capability-security -- the ability for objects in mutually
suspicious processes to safely cooperate. If it looks like E
and it quacks like E, it
might be a duck; but if it doesn't provide distributed capability security,
it's not E. A system that's
otherwise equivalent to E,
but doesn't provide distributed capability security, is called daffE.
A distributed E can only
be implemented by means of strong crypto, of course, for which we are
using code derived from the Cryptix
library (in accord with the terms of their open-source license). In a
space-local system, no distributed insecurity can arise, so such a system
would be an sl-E rather than
an sl-daffE.

E is designed to provide
local capabillity-security -- the ability for mutually suspicious objects
hosted by the same process to safely cooperate, and the use of capability
discipline to determine which of its hosting process's authorities it
may exercise. Such objects could be executing untrusted code --
code that the hosting process (or its owner) doesn't need to fully trust.

This is a "complete" release of E. "complete"
is in quotes, because both the persistence and the distribution leave
much to be desired, as explained here.
However, these are close enough that this release that doesn't need qualifiers
in its name.

Dependencies

Versions & Types of Java

In refering to various versions of Java, we follow Sun's terminology
and numbering. A Java Runtime, or jre, is adequate to run standard
Java binary programs (class files & resources). A Java Development
Kit, or jdk, is adequate both to build a program from sources and
to run it. A jdk is a superset of the corresponding jre, and their version
numbers are always in synch. Each successive version of the jdk/jre from
Sun effectively defines a new version of the Java & JVM standards,
except that Sun has introduced a numbering
inconsistency: The Java/JVM 2.x standard corresponds to Sun's jdk/jre
1.2.x. We ignore this inconsistency and refer to both as 1.2.x.

This version of E requires
a jre >= 1.3.1. E no longer supports Java < 1.3.1. To build E
from sources, a corresponding jdk is required.

Note: E does not install correctly when using JDK1.4beta on Windows2000
-- it fails to exec with "winfo.exe" executable, used during
install time to gather info about your Windows system. It seems to be
a more general problem in execing executables. If you experience this
problem, we suggest you install using a JDK1.3.*. Once installed, E should
work fine with either JDK1.3.* or JDK1.4beta.
( Track
this issue... )

Build-Only Dependencies

If you are only installing E
from a binary distribution, or only rebuilding the Java portion for your
own use, you can ignore this section. However, if you wish to build an
E distribution from sources,
then you will need the equivalent of the following tools as well.

The E building process relies
on a number of UNIX tools. These are available for Windows from Cygnus
Support as the Cygwin package. If you wish to build E
on Windows, you should download
and install a version >= 1.0.

BYacc/J (Berkeley Yacc for Java)

The E source distribution contains the executable binary program byaccj.exe
for Windows, and byaccj for Linux/386/glibc. These are actually
BYacc/Java
from Bob Jamison and others.
BYacc/Java is the Berkeley Yacc program extended with a "-j"
flag and others for producing Java output. BYacc/Java is covered by the
Berkeley License. If you are on a Unix system other than glibc Linux,
you need to download your own version of byaccj and overwrite
the one in src/bin/linux-386-glibc that our Makefile is using.

Note: The website at the above link, http://www.lincom-asg.com/~rjamison/byacc/,
seems to have disappeared. If you know where it may have gone to, or know
how to contact Bob Jamison, please let me know. In the meantime, starting
with the 0.8.10delta4 release, the sources to byaccj are bundled with
the E sources, and byaccj is made as part of making E.

Zip Files

Our build process packs up the *.zip files in the distribution
by using Info-Zip's
highy portable, and highly ported, zip program. Info-Zip's
zipping tools are open-sourced with a license that seems to resemble the
X11 license, but before redistributing it, you should read it for yourself.
The E distributions do not
bundle in these tools.

Unless stated otherwise, all text on this page which is either unattributed
or by Mark S. Miller is hereby placed in the public domain.