TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Proportional Font
Show HTML Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Content-transfer-encoding:
7BIT
Sender:
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Subject:
From:
"Criley, Marc A" <[log in to unmask]>
Date:
Mon, 10 Apr 2000 10:27:12 -0400
MIME-version:
1.0
Content-type:
text/plain; charset=iso-8859-1
Reply-To:
"Criley, Marc A" <[log in to unmask]>
Parts/Attachments:
text/plain (110 lines)
The following is a plain-text draft of a submission to the Defense
Information Systems Agency (DISA) recommending a change to the DII COE
standard prohibiting the use of compilers that convert languages other than
Java to Java byte codes.

If you wish to comment on this and add your name as a Submitter, please do
so.  A group of individuals who directly expressed interest in support of
this to me have been sent an early-look at this draft, but I am quite
willing to incoporate additional comments and criticisms.  I want to have
all comments received by me by COB Wednesday, 4/12, which I'll then
incorporate and distribute for final approval to those who have identified
themselves as submitters (rather than to the full Team Ada list).
Submission to DISA is scheduled for next Wednesday, 4/19.

Thanks for everyone's assistance!

Marc A. Criley

-----------------------------------------------------------------------

Recommended Modification to the Defense Information
Infrastructure Common Operating Environment (DII COE)
Integration and Run-Time Specification (I&RTS) 4.0


Location of Change

Section 8.2.3 (Miscellaneous), paragraph 4 (i.e., third bullet), reading as
follows:

"Developers shall not use compilers designed to convert code developed in
other languages (e.g., Ada, C++) to create Java byte-codes. This restriction
is important because such compilers may inadvertently bypass intended Java
security features."

Reasons for recommended modification

1. The justification for this restriction is in error. Neither the Java
programming language nor Java compilers in any way ensure conformance with
Java security features.
2. Prohibiting the compilation of all programming languages other than into
Java byte codes is a de facto mandate of the Java programming language for
all portable Web-based applications.

Recommended modification

Reword 8.2.3 (Miscellaneous), paragraph 4 (i.e., third bullet) as follows:

"Developers may use compilers designed to convert code developed in other
commercially supported languages (e.g., Ada, C++, Eiffel) to create Java
byte-codes. It is important to understand that it is the responsibility of
all Java Virtual Machines to properly verify Java byte codes and correctly
implement Java security features."

Technical Discussion for Recommended Change

Programs written in the Java programming language are compiled into Java
byte code (JBC) by a Java language compiler and placed in "class files".
Compilers for other programming languages may be targeted to generate JBC
class files as well, which then interoperate with those originally written
in Java or any other supported programming language. Currently there are
approximately 130 such compilation systems in production, development, or
research use, (http://grunge.cs.tu-berlin.de/vmlanguages.html), such as
JGNAT and AppletMagic for Ada, C2J++ for C++, JPython for Python, J-Eiffel
for Eiffel, even Java language assemblers such as Javaa and Jasmin.

A Java Virtual Machine (JVM) executes Java byte codes and is tailored for
the platform on which it executes, employing native GUI, file, connectivity,
security, etc., services to implement the Java run-time environment.

When executing a program consisting of a collection of JBC class files, the
JVM first invokes a "byte code verifier" to ensure that the classes contain
only valid byte codes in valid configurations. This is the first defense
against corrupted and security-violating class files. (Such classes may
result from disk or network corruption, or bugs or malicious hacks residing
in a compiler-regardless of the language it compiles, Java or another.)

The JVM itself must then properly implement the Java security model to
ensure that applications have access only to authorized capabilities of the
host platform, based on that system's security policy and the origin of the
application (applet, local or networked application, etc.)

Consider a Java applet written in Java that violates the Java security model
for applets. If such an applet is compiled by a Java language compiler that
(errantly) omits such checks, a verifiable Java class file is generated. The
only line of defense at this point is the JVM's implementation of the
security model enforcing the appropriate restrictions.

In no way does the Java programming language or a Java compiler ensure
anything regarding the content and integrity of generated Java byte codes.
Responsibility for enforcing Java security features relies solely on a
correct implementation of a platform's Java Virtual Machine. Therefore
claiming that permitting only the Java programming language as a source of
Java byte code class files ensures adherence to Java security features
reveals a dangerous misunderstanding.

Understanding that the JVM is responsible for system security and that the
source language originating a collection of JBC class files is irrelevant,
permits the use of other programming languages in application areas where
they may have particular advantages: Ada with its strong typing,
reliability, and safety features, Eiffel's support of "design by contract",
Python's object-oriented power represented with a simple, clear syntax.

It is ill-advised then to mandate the use the Java programming language in
application areas where it may be an inferior implementation language when
compared to another for which a robust, well-supported Java byte code
compiler exists.

---------------------------------------------------------------------------

ATOM RSS1 RSS2