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