Ben Laurie wrote: > 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?
It has generally been my experience that buffer overflows are not an issue in java code. Not because indexes are checked automatically, but more because the .length field is prevalently used. It is uncommon that I see IndexOutOfBoundsExceptions being thrown in my code, or the code I rely upon. Preventing buffer overflows is a commonly sighted advantage of java, but there are other advantages as well. There is a common architecture for signing and verification of code. The two JVMs I have installed return null when I attempt to get the signers of the String class. It would seem reasonable to me to have a hard coded public key in Harmony so we could verify the validity of the libs. These tools can also be used to seal jars, thus assuring that when someone downloads and installs a standard build of Harmony, they can be fairly certain that they didn't get an image with a back door built in. (Note this brings up a separate issue of having a SSL trusted host, but lets not go there yet.) Furthermore, by using the java.security package and it's friends we can be assured that our Java code is behaving correctly. If there is C code in the JVM which opens and writes to files, then we must manually check to see that the JVM has permission to do so. If the code is written in Java, then the SecurityManager class to takes care of that with no effort to the developer. This may be a double edged sword since developers who think "The SecurityManger will catch my bugs" are going to dig themselves into a hole. But it's better than the C model which is non-existant. Neil
