TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

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

Print Reply
Chad Bremmon <[log in to unmask]>
Thu, 6 Apr 2000 11:39:12 -0500
text/plain (63 lines)
Here's the deal. . . Java byte code is interpreted.  Any security issue is the
responsibility of the virtual machine.

Chad

"Criley, Marc A" wrote:

> I made the following postings on comp.lang.ada to get some general feedback,
> and Britt Snodgrass subsequently suggested I repost them to Team Ada.
>
> First the original posting:
>
> --------------------------------------------------------------------
>
> To Ada to JBC compiler vendors:
>
> Section 8.2.3 (Miscellaneous) of the Defense Information Infrastructure
> Common Operating Environment (DII COE) Integration & Run-Time
> Specification (I&RTS) v4.0 states that "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."
>
> Is this a legitimate concern?  I can kinda see how it might be, since
> for instance Java forbids things like uninitialized objects (though I
> vaguely recall some kind of exception to that), which Ada permits.  I
> suspect I could probably come up with some other potential problems if I
> dug into it.
>
> If the Ada to JBC compilers do not introduce the security risks that the
> I&RTS warns about, some educating is clearly called for.
>
> Marc A. Criley
>
> --------------------------------------------------------------------
>
> After getting the hoped-for raising of wrath and ire, I followed up with
> this:
>
> --------------------------------------------------------------------
>
> > Given the resounding repudiation of this prohibition against Ada (or
> > other language) to Java compilers, I'd like to try to get it removed.
> >
> > Though I'm not working on a DII COE compliant program, I'm going to try
> > to look at and work the process to get it removed.  If anyone
> > (particularly among those responding) has any technical material, white
> > papers, etc., with which to buttress this effort, I would be happy to
> > incorporate those into this drive.
> >
> > Alternatively, if someone feels they're in a better position to attack
> > this issue now that it's been identified, I'll defer to and support
> > them.
> >
> > Thanks for the responses.
> >
> > Marc A. Criley
> > Software Architect
> > Lockheed Martin M&DS
> > [log in to unmask]
> >

ATOM RSS1 RSS2