(j3.2006) (SC22WG5.4852) WG5 letter ballot on N1947

[Bill Long]

On 12/10/12 4:21 AM, John Reid wrote:
> This is a WG5 letter ballot on N1947, draft Fortran Annex to TR 24772,
> Guidance to Avoiding Vulnerabilities in Programming Languages through
> Language Selection and Use.
>
> Please answer the following question "Is N1947 ready for forwarding to WG23
> as the Fortran Annex to TR 24772?" in one of these ways.
>
> 1) Yes.
> 2) Yes, but I recommend the following changes.
> 3) No, for the following reasons.
> 4) Abstain.

I'm voting

2) Yes, but I recommend the following changes.

despite have a pretty long list of issues, because I'd like for this 
project to converge.  I've attached a separate file with the comments.

Cheers,
Bill



-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101


-------------- next part --------------
Simple typo or editorial issues:
--------------------------------

Page 1, Fortran.1: The uppercase letter "I" following "Corrigendum"
should be the number "1".

Page 5, def of "kind type parameters": I think it would be clearer if
"data" was inserted before "representation methods". This makes it
clear that we are not talking about, for example, the representation
of hardware instructions, which are also processor-dependent.

Page 5, def of "module": I would change "that are to be accessed" to
"that can be accessed". We don't require that modules actually be
used.

Page 7, Fortran.3.2, bullet 2: After "Use explicit conversion
intrinsics for conversions" insert " of values of intrinsic types".
Makes it clear that there are no such intrinsics for derived type
conversions.

Page 7, Fortran.3.2, bullet 4: Replacing "prevent unwanted" with
"avoid implicit" seems better to me.

Page 9, Fortran.5.1, para 3: In reference to floating point
quantities, I would prefer that "components" be changed to "parts".
Components could be confused with derived types, and the term "parts"
is used for the same thing in Fortran.5.2 bullet 5 on the same page.

Page 13, Fortran.9.1, top of page: I would insert "operations
involving" before "assumed-shape arrays", since arrays, by themselves,
do not have "performance", but rather the operations you do on them.

Page 14, Fortran.10.1: This seems pointlessly redundant with
Fortran.9 before it.  If it is necessary, then the same fixes for Page
13 need to be applied to the identical text on Page 14. (2 fixes).

Page 15, Fortran.11.1: para 4: In the last sentence, the Page 13 fix
needs to be applied here to yet another duplication of the identical
sentence.

Page 17, Fortran 14.1, para 2: Change "A Fortran pointer be default
are initially" to "A Fortran pointer by default is initially".

Page 17, Fortran.14.2, bullet 1: Change "Enable..." to "Use compiler
compiler options when available to enable...".  Use the same form as
elsewhere to refer to compiler options. Clarify that this is a
processor capability and not part of the language requirements.

Page 18, Fortran 15.2, bullet 3: Change	 "Enable..." to "Use compiler
compiler options when available to enable...". (Same issue as above.)

Page 19, Fortran.16.2, bullet 1: At the end, delete ", including long
into the future" as it is redundant with "anticipated".

Page 23, Fortran.24.1, para 1: Change "has never had a value stored in
it in undefined" to "has never been given a value is undefined".

Page 23, Fortran.24.2, bullet 1: Change "Favour" to "Favor". 
(Generally, remove British spellings where they differ from
US spellings. Search the pdf file for "our" to find them easily.)

Page 25, Fortran.28.1, para 3: Change "commented out" to "converted to
comments".

Page 27, Fortran.32.1, first sentence: Change "liable" to
"susceptible".

Page 31, Fortran.36.2, bullet 2: Change "especially since this" to
"especially if this".  The big win is IF the processor can detect
interface problems at compile time. The processor might also be able
to check at run time, but that is a different capability.

Page 33, Fortran.40.2, bullet 4: Change "Use a processor option, if
available, to" to "Use compiler options when available to". Style
consistency.

Page 38, Fortran.51.2, bullet 2: At the end, change "critical to
performance" to "performance is critical".

Page 40, Fortran.53.1, para 1: Change "MEM" to "Fortran.57".  Use
clearer and easier to find cross-references.

Page 40, Fortran.54.1, para 1: Change "[FAB]" to "Fortran.56". Use
clearer and easier to find cross-references.

Pages 40,41,42: Change the spelling of Behaviour/behaviour to
Behavior/behavior.


Editorial or Wording issues:
----------------------------

Page 1, author citation: I agree that the "Vulnerabilities Subgroup"
text should be removed. I wonder of "WG5" is sufficient, or should be
use the more formal "ISO/IEC JTC1/SC22/WG5"?

Page 1, Fortran.1: The first sentence will become false with the next
revision of the Fortran standard. It would be better if the beginning
of the sentence were "For the purposes of this Annex, the
International?. 

Page 2, Para 3: says "Annex B.1 of the Fortran standard lists six
features of Fortran that...".  These deleted features are NOT features
of Fortran.  Fixable with "...lists six features of older versions of
Fortran that..."

Page 13, Fortran.9.2, bullet 2: After "Use explicit interfaces and
assumed-shape" insert "or allocatable dummy" since allocatables also
work for this mitigation, but were omitted from the sentence.

Page 15, Fortran.11.1: para 4: Change "use an assumed-shape array as a
procedure argument" to "use an assumed-shape or allocatable array as a
procedure dummy argument". Include omitted allocatable array case (as
elsewhere) and also say that you mean dummy argument, rather than
actual argument.

Page 17, Fortran.14.2, bullet 2: There is no such thing as
"dereferencing" a pointer in Fortran. Change "dereferencing" to
"referencing".

Page 29, Fortran.34.1, para 1: After "pass-by-reference" insert ", by
value".  Important argument passing method was omitted from the list.

Page 29, Fortran.34.1, para3: In the first sentence, after "Module
procedures" insert ", intrinsic procedures, ".  An important case of a
procedure with an automatic interface was omitted from the list.

Page 30, Fortran.36.1, para 3: After "are provided automatically"
insert "for intrinsic procedures or". Again, omission of intrinsic
procedures as procedures with automatic interfaces.

Page 32, Fortran.38.2, bullet 1: Change "Code a status value..." to
"Code a status variable". You do not code the "value". Later in the
same sentence, change "examine the value" to "examine its value".

Page 32, Fortran.39.1, para 1: Change "(stop)" to "(stop or end
program)". Missing method for normal termination.

Page 35, Fortran.45.2, bullets 2 and 3: Why are these limited to
"intrinsic" procedures? The section is about library procedures, not
intrinsics, and it seems like these same recommendations would apply
to library procedures. Could be fixed by changing "intrinsic" to
"library" in bullet 2 and "an intrinsic" to "a library" in bullet 3.


Technical issues:
-----------------

Page 11, Fortran.7.2, bullet 2: I don't understand what "Ensure that
values from untrusted sources are checked..." means.  I assume
"untrusted sources" would be library routines you do not trust, or
data coming from files.  But in either case, to check the value, you
would already have in a variable (actual argument or input list item),
at which point it is too late to do any checking.  Bullet 3 is
similarly confusing about how you would actually do a check.  I would
propose deleting both bullet 2 and bullet 3.

I suspect what was intended is something like "When assigning an
expression of one type and kind to a variable of a type and kind that
might have a smaller numeric range, check that the value of the
expression is within the allowed range for the variable. Use the
inquiry intrinsics to supply the extreme values allowed for the
variable."  It that is the case, replace bullets 2 and 3 with
something like this.

Page 15, Fortran.11.1, para 3: The sentence "When a whole-array
assignment..." is not true if the array is a coarray. That restriction
needs to be included.

Page 17, Fortran.14.2, bullet 3: Says "Nullify...pointers before
referencing them." Really?  Remove "Nullify or" from the
beginning of the sentence.

Page 26, Fortran.29: This section ignores the Computed GOTO statement,
which seems to be a poster child for the vulnerability.  Computed GOTO
might be obsolescent, but it is still in the standard.  Add a sentence
in Fortran.29.1 something like "Fortran has a Computed GOTO statement
that allows control to flow from one alternative to another."  Then in
Fortran.29.2, add a second bullet "Avoid the use of Computed GOTO
statements."

Page 42, Fortran.58.1, bullet 1: Unless you go to absurd lengths,
detecting integer overflow is only practical if there is hardware
support for this capability. Requiring this level of hardware design
is generally outside the scope of the language standard.  Unless this
is a proposal for an IEEE standard, I would prefer that it be removed
from this section.