Secure Coding mailing list archives
Re: Programming languages -- the "third rail" of secure
From: Crispin Cowan <crispin () immunix com>
Date: Fri, 06 Aug 2004 17:28:33 +0100
Nick Lothian wrote: Scripting Languages: Depends on the language. Lack of type safety can be a problem, but on the other hand they are usually safe from buffer overflows and the fact they you can do a lot more in fewer lines of code can make the code safer by making errors more obvious. Scripting languages are a mixed bag: * On one hand, the dynamic type system and dynamic memory management eliminate buffer overflows as a problem. * On the other hand, the baroque language design (that there should be *several* ways to do something, which is at least an explicit design goal of Larry Wall for PERL) means that the programs can actually be very hard to read. Terseness means fewer lines of code to read, but obscurity can make those lines *very* difficult to understand. * Many scripting languages (PERL and PHP) have an unfortunate tendency to try really hard to interpret data. This results in fast prototype implementations, and also security faults as data gets interpreted just a little bit surprisingly :( Are there other languages in widespread use (ie, the language must be used more than - say - Python) that are safer than those listed above? Ruby zealots claim it has substantial advantages over python. I would be interested in comparative data from people exposed to both. Way, *way* back in the day, I dabbled with a shell scripting language called "rc" that came from the Plan9 community. It was a spartan language, which caters to my prejudice for parsimony. Is it still alive? Crispin -- Crispin Cowan, Ph.D. http://immunix.com/~crispin/ CTO, Immunix http://immunix.com
Current thread:
- RE: Programming languages -- the "third rail" of secure Nick Lothian (Aug 01)
- RE: Programming languages -- the "third rail" of secure coding ljknews (Aug 01)
- Re: Programming languages -- the "third rail" of secure Crispin Cowan (Aug 06)