Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: "Nasser M. Abbasi" Newsgroups: comp.lang.java.programmer Subject: Re: The CERT Oracle Secure Coding Standard for Java Date: Sat, 28 May 2011 00:42:22 -0700 Organization: Aioe.org NNTP Server Lines: 31 Message-ID: References: <899ac5cb-b1e4-44b1-8e27-e6385b4fdcdb@24g2000yqk.googlegroups.com> Reply-To: nma@12000.org NNTP-Posting-Host: TUXTYYqX1yG7hs3zxUg7ng.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 X-Notice: Filtered by postfilter v. 0.8.2 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:4680 On 5/27/2011 10:44 AM, rCs wrote: > The CERT Oracle Secure Coding Standard for Java has been completed and > is now ready for https://www.securecoding.cert.org/confluence/display/java/The+CERT+Oracle+Secure+Coding+Standard+for+Java. > > The CERT Oracle Secure Coding Standard for Java provides rules for > secure coding in the Java programming language. The goal of these > rules is to eliminate insecure coding practices that can lead to > exploitable vulnerabilities. > > To review, you can create an account on the wiki and then post > comments to any of the pages, or respond directly to me. > > Thanks, > rCs I thought Java was already secured? i.e. no buffer overflow problems like with C, and the sandbox thing for applets and all of that. I did not know that Java can be not secured before. But, would it be not better, if the language can be defined so that these remaining security holes that can make it not secure be closed at the language definition level, instead of having set of rules, that one need to print out and hang on the wall to look at while coding? This way the compiler job to spot them, not the programmer. Much better. Just asking, that is all. --Nasser