/ download

Download and Install E 0.8.9

Jump to

Known Installation Problems
Variants and Subsets of E
Dependencies
Download by Platforms & Versions

Are you sure you want the 0.8.9 version?

New!
E is Available Without Restriction

Historically, there have been two forms of "E". E itself, employing the kind of strong cryptography parts of the U.S. government tried to prevent from being exported, and deffE, which was crypto-crippled to appease these bureaucrats. Domestically, we produced and exported only daffE. E was then independently derived and distributed overseas.

With two changes in the U.S. legal climate, this dance is no longer necessary.

• The Ninth Circuit Court rules Software is Protected Speech and Export Controls are Unconstitutional Prior Restraint. The Ninth Circuit consists of California, Oregon, Washington, Arizona, Montana, Idaho, Nevada, Alaska, Hawaii, Guam and the Northern Mariana Islands. E is produced, published, and distributed primarily from California.

• Although still a long way from being constitutional, the Bureau of Export Administration (BXA), issues new regulations that mostly legalize the export of freeware strong crypto code. E, being open source, qualifies by their definition of freeware: "not subject to an express agreement for the payment of a licensing fee or royalty for commercial production or sale of any product developed with the source code". The "mostly" is that the new regulations require that the BXA be notified of any such exporting. As this restriction clearly constitutes an unconstitutional prior restraint on speech, we hereby exercise our constitutional rights by posting E without restriction (thereby effectively exporting it) without notifying the BXA. We encourage other purveyors of strong crypto code to do likewise.

We will no longer be distributing of supporting any flavor of daffE -- only E..

Known Installation Problems

All the Windows installation problems known as of 0.8.7 are fixed. At this moment, we don't know of any installation problems with 0.8.9, but as we find out, we'll list them here. Also, check out the thread rooted in the release notes.

Since this release was announced, three problems have surfaced.

1. As explained here, an E running on a Sun-derived Java 1.1.x will not succeed at communicating with one running on a Sun-derived Java 1.2.x.

2. On Linux, E neither builds nor installs using Blackdown Java (a Sun-derived Java) 1.1.x, though it builds and installs fine with Blackdown Java 1.2.x.

3. Although E seems to install fine on Win95, Win98 First Edition, WinNT, and Win2000, as explained here, it fails to install on Win98 Second Edition. This has not yet been diagnosed.

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.

A non-persistent E is called time-local since an object only exist as long as its hosting process does. This release is time-local and so is prefixed with "tl-". We expect to be adding the persistence code back in as part of the 0.9.x release.

A non-distributed E is called space-local if an object and all references to it only exist within its hosting process. This release is distributed and so is not prefixed with "sl-". To make a space-local variant of this release, you need merely remove the org.erights.e.net package tree.

E by 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 bundling a subset of the Cryptix library. In a space-local system, no distributed insecurity can arise, so such a system would be an sl-E rather than an sl-daffE. This release provides distributed security and so is an E rather than a 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. Currently, however, E's E-to-Java binding exposes all of public static Java to all E code, and the Java libraries do not follow capability discipline. Therefore this release hosts only-trusted-code and so is prefixed with "otc-". (Note that all conventional cryptographic code, such as PGP, is also assumed to be fully locally trusted, and provides only distributed security.) We expect to provide local capability security, including confinement, as part of the 1.0.x release.

E is designed to support automatic mobile code (as in PassByCopy objects). However, were this to be provided in a release that was not locally secure, this would invalidate our distributed security and worse. Therefore mobile code support must wait until E supports full local capability security including confinement.

Dependencies

Versions & Types of Java

In referring 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 2.x.

E requires a jre >= 1.1.7. To build E from sources, a corresponding jdk is required.

E makes heavier use of Java reflection than most Java vendors have encountered. Some implementations of Java (like IBM's VisualAge 1.1.7) have failed to run E because of bugs in their implementation of reflection. As you encounter information to add to the table below, please let me know.

Some places to get some a jre or jdk:

Versions of Cryptix

This release of E bundles in, and depends on, a subset of the Cryptix 3.1.1 strong cryptography library. This library is compatible with both Java 1.1 & Java 2. However, it is not compatible with the Java Cryptography Extension (JCE) 1.2. This library is covered by the Cryptix General License, which is the standard Berkeley license without the hated advertising clause. Note: This release of Cryptix doesn't work if you rename the *.jar files, so leave 'em alone. The "e" command includes the names of these files in the CLASSPATH it provides to Java.

This is a snapshot of a future version of Cryptix that is JCE 1.2 compatible, while still supporting Java 1.1. We know of no reason why it shouldn't just work with E. If you try it, please let me know what happened. Thanks.

Versions of Swing

E depends on the availability of a Swing whose package path is "javax.swing" (rather than the older "com.sun.java.swing"). We did not include it directly in the download files because:

1. Many Java implementations already contain a Swing implementation using "javax.swing".
2. The jar file is over 2MB
3. The one we've got (Sun's) isn't open source.

Java 2.x already contains such a Swing, as do some implementations of Java 1.1.x. If your's doesn't, here is Sun's no-cost download page for adding such a Swing to Java 1.1.x.

Alternatively, you can download swingall.jar and, after installing E, place it in

<E-install-dir>/bin/jars/swingall.jar

The "e" command includes this name in the CLASSPATH it provides to Java.

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 Cygwin Distribution

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 at least Beta version 20.

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.

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.

Download by Platforms & Versions

Earlier versions of E have been tested and run on Windows 95, Windows 98, and Linux. It should run without difficulty on Windows NT and on other UNIX platforms. If you experience any problems, please let me know.

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.

The contents of the Unix/Linux source distributions are identical to that of the Win* source distributions, except for the use of gzipped tar files rather than zip files, and the use of respective platform's newline conventions for the text files. Since gzipped tar files are somewhat smaller, Win* users should download these instead if they can decompress them and if their tools are tolerant of the Unix newline convention. The commercial WinZip program seems to do a good job on both compression types. Also, Info-Zip's unzip can be used to unpack the zip files on any platform.

The binary distributions, on the other hand, are specific to each platform. We do not currently cross-compile. The Linux binary distribution is built from the common source distribution on Linux, and similarly for Windows. The link above is a Linux binary distribution for the 386 architecture and a glibc-supporting version of Linux (this includes RedHat 6.1, which is what we're using). If you need E for a different Unix/Linux configuration, you should build E from the source distribution.

javadoc.tar.gz contains the javadoc-umentation of the ELib Java API, obtained by Javadocing the E source tree.