1995-10-09 - Re: Java

Header Data

From: “Perry E. Metzger” <perry@piermont.com>
To: Ray Cromwell <rjc@clark.net>
Message Hash: 4d31e5b41a8011bdabe90c0b515bfcfd32742426679c4c97565e02db1c751ecc
Message ID: <199510090325.XAA04766@jekyll.piermont.com>
Reply To: <199510090307.XAA10293@clark.net>
UTC Datetime: 1995-10-09 03:25:57 UTC
Raw Date: Sun, 8 Oct 95 20:25:57 PDT

Raw message

From: "Perry E. Metzger" <perry@piermont.com>
Date: Sun, 8 Oct 95 20:25:57 PDT
To: Ray Cromwell <rjc@clark.net>
Subject: Re: Java
In-Reply-To: <199510090307.XAA10293@clark.net>
Message-ID: <199510090325.XAA04766@jekyll.piermont.com>
MIME-Version: 1.0
Content-Type: text/plain



Ray Cromwell writes:
>   Well those concerns are all fine and swell, but the same kind
> of reasoning applies to any network application. There are buffer overflow
> bugs in almost every web browser, there are overflow bugs in CERN HTTPD3.0,
> and who knows, there are probably bugs in ELM/PINE.

I believe that the security related ones in those applications are
well within human ability to fix -- simply implementing some hygenic
coding practices stops them. I don't believe that is the case with
Java implementations. I don't know how I'd manage to produce a "safe"
Java. Its a neat programming language, by the way -- its only when you
rig yourself to automatically run code produce by hostile people that
the issue comes up.

>   And the situation without Java is not much better. Most of Java 
> functionality is faked with CGI scripts, usually written in perl,
> and there are plenty of ways to screw up a CGI implementation to allow
> holes.

Thats true, but again, there is the alternative of gaining the
functionality with truly safe languages.

>   Java is mostly a risk to consumers (the users with the browsers), and
> not corporate networks who are running servers, *unless* the employees
> are using Java on the firewalled network. 

Unfortunately, it will be very hard to stop people from doing just
that.

Perry





Thread