Re: [SC-L] Compilers
* Crispin Cowan: I'm with you on the C and C++ argument, but what is immature about Java? I thought Java was a huge step forward, because for the first time, a statically typesafe language was widely popular. Java is not statically typesafe, see the beloved ArrayStoreException (and other cases, depending what you mean by statically typesafe). So every language that supports arrays is not statically type safe? No, the Java case is a bit peculiar because of the array subtyping rules. If B extends A, a B[] is also an A[], but you cannot actually store As into such an A[]. This is enforced by a run-time check (which raises ArrayStoreException, which is not triggered by an out-of-bounds array access), and I think it means that Java is not statically typesafe by any reasonable definition (or, at least, its arrays aren't). What language does better on array bounds typing? This wasn't my point, but: There has been some work in this area (particularly in respect dependent types), IIRC. But such type systems tend to be undecidable in general, and type inference is both a must and pretty difficult. I'm not sure if this is a significant issue as far as secure coding is concerned because in many systems, you can restrict the code which relies heavily on bounds checking (typically some sort of parser) to a module, and if a failure occurs, you discard the PDU that trigger it. The parser itself can be constructed using a statically verifiable domain-specific language, or if the protocol is rather baroque, using tools like SPARK, to minimize PDU drops due to coding errors. And in the case of Java, null pointer exceptions seem to be a far greater threat to reliability than array bounds checks. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Compilers
At 2:18 PM + 1/2/07, Peter Amey wrote: [snip] Isn't the whole basis of Spark a matter of adding proof statements in the comments ? I don't think the general compiler marketplace would go for that built-in to compilers. After all: 1. The Praxis implementation can be used with multiple compilers 2. The compiler market is so immature that some people are still using C, C++ and Java. But for the high-integrity market, Spark seems to fit the bill. -- Larry Kilgallen We think so! However, like everything else, it is how you use things that matter most. How you use things may be an essential aspect, but so is the nature of things. Achieving the same quality by toggling the machine code into the front panel is only possible on a theoretical basis, and getting the same results with a long strand of limp spaghetti is just impossible. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Compilers
[snip] Isn't the whole basis of Spark a matter of adding proof statements in the comments ? I don't think the general compiler marketplace would go for that built-in to compilers. After all: 1. The Praxis implementation can be used with multiple compilers 2. The compiler market is so immature that some people are still using C, C++ and Java. But for the high-integrity market, Spark seems to fit the bill. -- Larry Kilgallen We think so! However, like everything else, it is how you use things that matter most. What SPARK allows is very effective secure coding (what this list is all about). There is an entry on this subject on the Build Security In website: https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/sdlc/61 3.html. regards Peter ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Compilers
I think my perspective is not just about overlap in terms of an abstract syntax tree but more in terms of usability. Security warnings should appear inline with other types of warnings from a developers perspective. When the information is presented separately, it will be an opportunity to ignore. It is harder to ignore compiler output. Likewise, one of the lifecycle oriented things I have seen in several shops is that source code gets moved through environments and gets recompiled. So if I check in code to the integration environment, the build tool will extract and compile. Likewise, when code gets promoted to say QA environment, the code is extracted again and recompiled. This allows for build tools that emit metrics and track warnings in a centralized place to take advantage of security considerations as well. Of course, some shops when they promote code move binaries which invalidates the above. -Original Message- From: Temin, Aaron L. [mailto:[EMAIL PROTECTED] Sent: Thursday, December 21, 2006 1:38 PM To: McGovern, James F (HTSC, IT); Secure Coding Subject: RE: [SC-L] Compilers It would be worth knowing more about the basis you use for drawing the conclusion, but if it's just the overlap between compilers and static analyzers represented by the abstract syntax tree, I don't think that's enough to warrant building one into the other (it might argue for having a shared parser, but I don't think parsers are hard enough to build to make that worthwhile). I would also suggest that looking for security weaknesses fits more into the unit testing part of development rather than the compiling part. As for standalone, I think Jtest is built as an Eclipse plug-in; I don't know if you'd consider that standalone or not, but at least the developer doens't have to start up another shell to run it. Also, depending on the customer's organization, it might not be the developer who is running the security static analysis. I was talking with an organization that was thinking of having the security group run the static analysis, as part of the acceptance phase of an iteration. - Aaron _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of McGovern, James F (HTSC, IT) Sent: Thursday, December 21, 2006 10:31 AM To: Secure Coding Subject: [SC-L] Compilers I have been noodling the problem space of secure coding after attending a wonderful class taught by Ken Van Wyk. I have been casually checking out Fortify, Ounce Labs, etc and have a thought that this stuff should really be part of the compiler and not a standalone product. Understanding that folks do start companies to make up deficiencies in what large vendors ignore, how far off base in my thinking am I? * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Compilers
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ljknews Sent: 02 January 2007 14:20 To: Secure Coding Subject: Re: [SC-L] Compilers At 2:18 PM + 1/2/07, Peter Amey wrote: [snip] We think so! However, like everything else, it is how you use things that matter most. How you use things may be an essential aspect, but so is the nature of things. Achieving the same quality by toggling the machine code into the front panel is only possible on a theoretical basis, and getting the same results with a long strand of limp spaghetti is just impossible. Larry, I don't think I was intending to disagree with you! The right languages /allow/ demonstrable secure coding. Conversely, without them, secure coding is reduced to a fairly weak coding standard level. Peter P.S. Please watch for the unfortunate word wrap in the URL of my original post. The broken link still works but goes to thw wrong place! ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Compilers
| ...P.S. Please watch for the unfortunate word wrap in the URL of my | original post. The broken link still works but goes to thw wrong place! Now, *there's* an interesting hazard! One can imagine some interesting scenarios where this could be more than unfortunate. At the least, it could be (yet another) way to hide the true target of a link. -- Jerry ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Compilers
| I _strongly_ encourage development with maximal warnings turned on.
| However, this does have some side-effects because many compilers
| give excessive spurious warnings. It's especially difficult to
| do with pre-existing code (the effort can be herculean).
Agreed. Writing for maximum freedom from warnings is a learned skill,
and a discipline. Mainly it involves avoiding certain kinds of
constructs that, when all is said and done, are usually as confusing
to human readers as they are to compilers. There is a great deal of
overlap among writing for no warnings, writing for maximum
portability, writing for clarity, and writing for provability.
What they all come down to is: The code sticks to the meaning of
the language definition and avoids all ambiguity; it has only one
possible interpretation, and coming to that interpretation requires
minimum work.
That said, there will always be cases where maximum speed, minimum
size, or some other external constraint drive you to do things that
don't meet these constraints. Some of these are reasonable. Bubble
sort is obviously correct; no O(N log N) sort is. There are
places where you have to use comments to refer to a proof and the
kind of checking required becomes very different. And there are
places where every nanosecond and every byte really matters. The
conceit of all too many programmers is that *their* code is
*obviously* one of those cases. It almost certainly isn't.
| An interesting discussion about warning problems in the Linux kernel
| can be found here:
| http://lwn.net/Articles/207030/
There's example given there of:
bool flag = false;
some_type* pointer;
if (some_condition_is_true()) {
flag = true;
pointer = expensive_allocation_function();
}
do_something_else();
if (flag) {
use_the_fine(pointer);
}
The compiler will warn that the call to use_the_fine() might be
called with an uninitialized pointer. Noticing the tie between
flag being true and pointer being initialized is beyond gcc,
and probably beyond any compiler other than some research tools.
Then again, it's not so easy for a human either beyond a trivial
example like this!
There's an obvious way to change this code that is simultaneously
warning-free, clearer - it says exactly what it means - and smaller
and equally fast on all modern architectures: Get rid of flag,
initialize pointer to NULL, then change the test of flag to test
whether pointer is non-NULL. (Granted, this is reading into the
semantics of expensive_allocation_function().) Someone mentions
this in one response, but none of the other respondents pick up
on the idea and the discussion instead goes off into very different
directions.
There's also no discussion of the actual cost in the generated code
of, say, initializing pointer to NULL. After all, it's certainly
going to be in a register; clearing a register will be cheap. And
the compiler might not even be smart enough to avoid a pointless
load from uninitialized memory of pointer is *not* given an
initial value.
(There is one nice idea in the discussion: Having the compiler
tell you that some variable *could* have been declared const,
but wasn't.)
I find this kind of sideways discussion all too common when you
start talking about eliminating warnings.
| Ideally compiler writers should treat spurious warnings as serious bugs,
| or people will quickly learn to ignore all warnings.
| The challenge is that it can be difficult to determine what is
| spurious without also making the warning not report what it SHOULD
| report. It's a classic false positive vs. false negative problem
| for all static tools, made especially hard in languages where
| there isn't a lot of information to work with.
Having assertions actually part of the language is a big help here.
This is all too rare.
-- Jerry
| --- David A. Wheeler
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___
Re: [SC-L] Compilers
* Crispin Cowan: ljknews wrote: 2. The compiler market is so immature that some people are still using C, C++ and Java. I'm with you on the C and C++ argument, but what is immature about Java? I thought Java was a huge step forward, because for the first time, a statically typesafe language was widely popular. Java is not statically typesafe, see the beloved ArrayStoreException (and other cases, depending what you mean by statically typesafe). And if you allow for more dynamic typing, Visual Basic gained more widespread usage even earlier. 8-P ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Compilers
I _strongly_ encourage development with maximal warnings turned on. However, this does have some side-effects because many compilers give excessive spurious warnings. It's especially difficult to do with pre-existing code (the effort can be herculean). An interesting discussion about warning problems in the Linux kernel can be found here: http://lwn.net/Articles/207030/ Ideally compiler writers should treat spurious warnings as serious bugs, or people will quickly learn to ignore all warnings. The challenge is that it can be difficult to determine what is spurious without also making the warning not report what it SHOULD report. It's a classic false positive vs. false negative problem for all static tools, made especially hard in languages where there isn't a lot of information to work with. --- David A. Wheeler ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Compilers
Tim Hollebeek [mailto:[EMAIL PROTECTED] wonders: are shops that insist on warning free compiles really that rare? Yes. I've worked for or with many companies over the years, totalling probably somewhere in the mid-teens or so. In all that, there was, to the best of my recollection, only ONE that insisted on it, other than my own one man show. Add to that, numerous open source apps I've compiled; I haven't kept track of how many were warning-free, but it's rare enough that I consider it a pleasant surprise. In several projects, I fixed some nasty bugs (inherited from other people) by turning warnings on (they were often totally suppressed!), and fixing the things that the warnings were trying to warn me about. This is of course obvious to you and me, and probably to most of this list, but apparently not to the vast majority of programmers (even so-called software engineers), let alone people in any position of authority to set such policies. :-( -Dave -- Dave Aronson Specialization is for insects. -Heinlein Work: http://www.davearonson.com/ Play: http://www.davearonson.net/ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Compilers
However, not all of the kinds of things should be put in the compiler (how many coders do you know that use the -Wall??!). All the decent ones??? I remember people talking about Warning free with -Wall as a minimal requirement, and personally using that standard, over 15 years ago. And that was just for code quality reasons. Granted, many monkeys with keyboards were pulled into the industry during the 90s IT boom, but are shops that insist on warning free compiles really that rare? I'm not sure How can we create secure software in an environment where people don't even conform to minimalist software engineering principles? is a helpful topic for discussion as a way forward, no matter how useful it may be as a source for tool and consulting revenue. Tim Hollebeek Research Scientist Teknowledge Corp. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Compilers
ljknews wrote: 2. The compiler market is so immature that some people are still using C, C++ and Java. I'm with you on the C and C++ argument, but what is immature about Java? I thought Java was a huge step forward, because for the first time, a statically typesafe language was widely popular. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering, Novell http://novell.com Hacking is exploiting the gap between intent and implementation ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Compilers
On 12/22/06, Gary McGraw [EMAIL PROTECTED] wrote: I have a better idead. Stop using C++. Jeeze. Even better then that; stop programming insecurely. gem *rolleyes* -- mic ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Compilers
On 12/21/06, Gary McGraw [EMAIL PROTECTED] wrote: I have a better idead. Stop using C++. Jeeze. I'll second that recommendation. Given the abundance of better languages, there are few good reasons to use dangerous languages like C++ on new projects. It's easier and less time consuming to learn a new safe language than to use C++ securely. James Walden ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Compilers
On 12/21/06, Stephen de Vries [EMAIL PROTECTED] wrote: You can achieve very similar goals by using unit tests. Although the tests are not integrated into the code as tightly as something like Spark (or enforcing rules in the compiler), they are considered part of the source. IMO unit and integration testing are vastly underutilised for performing security tests which is a shame because all the infrastructure, tools and skills are there - developers (and security testers) just need to start implementing security tests in addition to the functional tests. I agree that it's important to test the security of your software and I like test-driven development, but unit tests are not a replacement for static analysis assisted code reviews. Likewise, static analysis and code reviews aren't a substitute for security testing. Security tests attempt to find bad input and verify that the program handles it correctly, but you can't guarantee that you've found every possible type of bad input. Unit tests have the additional problem that input which may be safe for the current unit may become dangerous when interpreted differently in a different unit of the program (e.g., ' OR 1-1--' is just text to your web application, but your database may interpret it as code.) Code reviews find different bugs than tests do, and they typically find them faster, so good testing practices are not an excuse to ignore static analysis and code reviews. Tests also find different bugs than code reviews do. If your static analysis tool doesn't have a rule to detect a particular class of security bug, it obviously won't find it, but your testers might have the experience to test for it. James Walden ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Compilers
Integration of some of the static techniques found in tools like fortify into compilers does make sense. However, not all of the kinds of things should be put in the compiler (how many coders do you know that use the -Wall??!). So one use case for some of the knowledge would be compiler enforcement. Note that compilers are notorious for computing and then throwing out many things statically. They are designed to get their transformation business done, not to do real analysis. Still other things should be worked directly into the languages. C and C++ suck for security. And most importantly, rules tailored directly to the enterprise situation at hand require a platform like fortify. At cigital we have developed sets of custom rules for customers with great results. This cuts down false positives and makes it possible to enforce guidelines and standards that make sense for the business (think J2EE here). Bottom line...we need it all, and we need it now. gem P.S. Ken's course was co-designed by me and is based on my book. You might pick up a copy. company www.cigital.com podcast www.cigital.com/silverbullet book www.swsec.com -Original Message- From: McGovern, James F (HTSC, IT) [mailto:[EMAIL PROTECTED] Sent: Thu Dec 21 10:47:50 2006 To: Secure Coding Subject:[SC-L] Compilers I have been noodling the problem space of secure coding after attending a wonderful class taught by Ken Van Wyk. I have been casually checking out Fortify, Ounce Labs, etc and have a thought that this stuff should really be part of the compiler and not a standalone product. Understanding that folks do start companies to make up deficiencies in what large vendors ignore, how far off base in my thinking am I? * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * This electronic message transmission contains information that may be confidential or privileged. The information contained herein is intended solely for the recipient and use by any other party is not authorized. If you are not the intended recipient (or otherwise authorized to receive this message by the intended recipient), any disclosure, copying, distribution or use of the contents of the information is prohibited. If you have received this electronic message transmission in error, please contact the sender by reply email and delete all copies of this message. Cigital, Inc. accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this email or its contents. Thank You. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Compilers
Sure it should be built into the language, and I assume it will be eventually. Heck it only took 30 or 40 years for people to force developers to use Try...Catch blocks. -gp On 12/21/06 9:30 AM, McGovern, James F (HTSC, IT) [EMAIL PROTECTED] wrote: I have been noodling the problem space of secure coding after attending a wonderful class taught by Ken Van Wyk. I have been casually checking out Fortify, Ounce Labs, etc and have a thought that this stuff should really be part of the compiler and not a standalone product. Understanding that folks do start companies to make up deficiencies in what large vendors ignore, how far off base in my thinking am I? * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Compilers
McGovern, James F \(HTSC, IT\) I have been noodling the problem space of secure coding after attending a wonderful class taught by Ken Van Wyk. I have been casually checking out Fortify, Ounce Labs, etc and have a thought that this stuff should really be part of the compiler and not a standalone product. Understanding that folks do start companies to make up deficiencies in what large vendors ignore, how far off base in my thinking am I? You're on-track. Indeed, you can see little pieces of it happening. I'll use gcc as an example, because it's one of the most widely used C/C++ compilers in the world. In the last few years much has been added to gcc, including the ability to detect format string errors and many mechanisms to help counter buffer overflows (randomization, StackGuard later IBM's ProPolice sort-of-reimplementation, etc.). I expect more detection and prevention mechanisms to go into gcc C/C++ compilers in the future. But I think you're not going far enough back. Compilers or interpreters are very much limited by the language (notation) they're trying to support. It's hideously hard to retrofit many kinds of detection into C/C++, because programs written in those notations just don't have enough information to easily determine if things are okay. Buffer overflows are an obvious example; they can't even OCCUR in most languages, but are rife in C/C++ because information about buffer size is not necessarily available to a buffer user (yes, I know about C++'s STL, but you don't HAVE to use it). Which is why separate tools are used -- the analysis work can be hideously hard. It's better to have a language (including its library) where the problem can't occur (e.g., because it's trivial to detect it) or is at least unlikely/hard (e.g., make the easy way the secure way). Java (and its clone C#) avoid many problems by DESIGN instead of happenstance, e.g., you can't (normally) have buffer overflows (in normal protected code they can't happen). Even stupid stuff like = vs. == mixing goes away (mostly). If a language is designed to make it EASY to do the right thing, the right thing is more likely to occur. PHP, especially old versions, is an obvious case in point. Old versions (where global_registers was true by default) are almost impossible to write secure software for. I will say that at least the PHP folks were willing to change their language when it was realized that their language's design made it nearly impossible to be secure. I wish they'd take more steps, but on the other hand, other language communities are unwilling to take even small steps to eliminate sharp edges from their languages. --- David A. Wheeler ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
