These are supposed to be rules that a programmer should adopt to
make the code written by that language more 'safe' and 'secure'
Here is the one for C for example
https://www.securecoding.cert.org/confluence/display/seccode/CERT+C+Secure+Coding+Standard
I was wondering if Ada would benefit of having something like this?
such secure programming rules customized for Ada.
Or if it is even needed as much for Ada? Some of the rules
seem good to know about
May be some of this material is allready in the Ada rational in
different places. not sure now.
--Nasser
> I saw that CMU makes now what is called CERT (secure coding standards)
> for different languages. They have Java, C, C++ in there.
>
> These are supposed to be rules that a programmer should adopt to
> make the code written by that language more 'safe' and 'secure'
>
> Here is the one for C for example
>
> https://www.securecoding.cert.org/confluence/display/seccode/CERT+C+Secure+Coding+Standard
You can guess these recommendations are all languages specific. Ex. the
common recommendation to write
if (condition) {
do ();
}
instead of
if (condition)
do ();
makes no sense for Ada, which has already handle this: you always write
if Condition then
do;
end if;
There is no other way to do, so no rules to have there.
Well, this matters about how-to-write are mostly already embedded in the
language rules (that is one of its target: readability, and principle of
least-surprise).
Except that, there already exist to some Ada subset, or profiles. One of
the most common is the one which is required with SPARK. Here again, no
need to setup some rules and ask the authors to follow these rules and
nothing else, as these are already checked by the SPARK Checker.
But nothing is perfect, there may be some interested rules to be applied
to Ada, just that there will be few, and there all should be mostly domain
specific, as the ones about the large principles, are already there (I
believe).
--
“Syntactic sugar causes cancer of the semi-colons.” [Epigrams on
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
“c++; /* this makes c bigger but returns the old value */” [Anonymous]
This is addressed by ISO/IEC JTC 1/SC 22/WG 23 Programming Language
Vulnerabilities[1].
There are language-specifix annexes for Ada, SPARK and several other
languages. The annexes for Ada and SPARK are in the Ada User
Journal[2], Volume 32, No 3 and 4 respectively.
[1] http://www.aitcnet.org/isai/
[2] http://www.ada-europe.org/journal.html
--
Ludovic Brenta.
>
> Except that, there already exist to some Ada subset, or profiles. One of
> the most common is the one which is required with SPARK. Here again, no
> need to setup some rules and ask the authors to follow these rules and
> nothing else, as these are already checked by the SPARK Checker.
>
That was my initial reaction to when I saw those rules,
is that a well designed secure language, would not need such rules
(or much of then any them) for a programmer to remember, since
the compiler will check and reject code written which is 'not secure'
as it will be something not allowed at the language level itself.
But when I said that in the Java newsgroup I got screamed at :)
Most of the rules seem to target handling strings, where,
as one would expect, most of the security problems can sneak in.
The funny thing, is that Java 7 just added a switch on string !
http://www.vineetmanohar.com/2011/03/new-java-7-feature-string-in-switch-support/
So, may be now more rules needs to be added for the programmer
to remember when using this new feature added by the language,
so they can use it in 'secure' way.
--Nasser
A good idea, but they still did not removed the requirement of an explicit
Break and the end of each case, so that is still not a real Switch, that's
still a Goto.
switch (color) {
case "red":
System.out.println("Color is Red");
break;
case "green":
System.out.println("Color is Green");
break;
default:
System.out.println("Color not found");
> https://www.securecoding.cert.org/confluence/display/seccode/CERT+C+Secure+Coding+Standard
I wouldn't have rated
https://www.securecoding.cert.org/confluence/display/seccode/POS39-C.+Use+the+correct+byte+ordering+when+transferring+data+between+systems
as a _guideline_ exactly!
Or
https://www.securecoding.cert.org/confluence/display/seccode/FIO09-C.+Be+careful+with+binary+data+when+transferring+data+across+systems
come to that.
There are references to Ada in the NASA Software Safety Book, it is
worth reading and can be downloaded freely at:
> There are references to Ada in the NASA Software Safety Book, it is
> worth reading and can be downloaded freely at:
>
> http://www.hq.nasa.gov/office/codeq/doctree/871913.pdf
Excellent link, thanks! (it may be dated 2004, but it doesn't seem
dated).
In the particular area of Object Oriented Design applied to High-Integrity
applications, there is one AdaCore worked on:
www.open-do.org/wp-content/uploads/2011/04/HighIntegrityAda.pdf
(I have this in my archive directory, but did not read it so far)
I know Jean-Pierre Rosen also took part to a similar workshop, but I have
no reference to this.
> Or if it is even needed as much for Ada?
Apparently it is, as several such documents were written for Ada.
Apart from those already mentionend, these two might be of interest:
"Ada95 Trustworthiness Study: Guidance on the Use of Ada95 in the
Development of High Integrity Systems"
ISO/IES TR 15942: "Guide for the use of the Ada programming language
in high integrity systems"
--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com
Note for people not very versed in Ada reading this thread: these papers
does not suggest Ada is not safe; on the opposite, these are all
recommendations to be applied when a hard step above typical safety
requirement one may find with everyday applications are required; none is
required outside of so much heavy requirements.
> On 28 Maj, 20:53, "Nasser M. Abbasi" <n...@12000.org> wrote:
>
>> Or if it is even needed as much for Ada?
>
> Apparently it is, as several such documents were written for Ada.
>
> Apart from those already mentionend, these two might be of interest:
>
> "Ada95 Trustworthiness Study: Guidance on the Use of Ada95 in the
> Development of High Integrity Systems"
I don't think the CERT guide is targeted at high-integrity systems.
It's intended for an extremely broad range of things, from server
software to productivity applications for end users. This means that
certain features are taken for granted, such as the need to restart
applications from time to time (because of a non-compacting dynamic
memory manager) and the ability of software to scale with available
resources.
The most recent volume on that website is Volume 32, No 1, dated March 2011.
Are you saying that these annexes are due for publication later this year,
or is the above volume number incorrect ?
Thanks,
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
It's volume 31, but the text is not yet online, only the table of
contents.
Thanks for clarifying.
Are the annexes available from any other online source ?
A quick search using the first URL only found what was classed as
historical material for Ada 83.