Neil Macneale wrote:
Hello All-
I've been lurking for awhile and I think the significant discussion
about security in the Harmony JVM has been missing. Considering such
ideas as hot compiling code and making it executable sets off big alarm
bells in my head.
One huge pitfall in many software projects is putting off security until
later. Auditing of code becomes much more difficult as the code base
become large. Furthermore, as code grows old, people forget how it works.
Somehow the java gods have convinced the world that java is secure. But
that all relies on a the JVM executing as documented and with no
security holes of it's own. The number of ways in which a JVM could open
security vulnerabilities in a system is enormous, and this is amplified
by the fact that the language it self has a security model which is
fairly complex.
One of the reasons I am in favor of implementing as much of the JVM in
Java is that I think it is easier to write secure code in Java than in
C/C++. A small core in C/C++ would be reasonable, but from a reviewers
standpoint it is more difficult to guarantee that a piece of C code is
secure. Generally speaking, of course.
I'd be happy to read people's code and look for bugs, and I may end up
doing this just for yucks. Are other people concerned about this?
Thoughts, comments?
I was initially tempted to say "those who do not read the archives are
doomed to repeat them" but I guess this is (yet another) slightly
different slant on the debate.
So, it seems to me that when you say its easier to write secure code in
Java than C what you really mean is that its easier to write code free
of buffer overflows in Java than C.
I can't think of _any_ other interesting security properties that Java
has and C lacks. Am I missing something?
Cheers,
Ben.
--
>>>ApacheCon Europe<<< http://www.apachecon.com/
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff