- 13 July 2008: 09:00 to 12:00 and 13:30 to 17:00
- 14 July 2008: 09:00 to 12:00 and 13:30 to 17:00
- 15 July 2008: 09:00 to 12:00
Standards Council of Canada
2nd Floor, 270 Albert St.
Ottawa, Ontario
Canada
- Standards Council of Canada
stephen.michell@maurya.on.ca
1.1 Opening Comments (Michell, Benito)
The meeting was convened at 9:00 am. Steve Michell described the meeting facility. Lunch will be brought in each day.
1.2 Introduction of Participants/Roll Call
John Benito (convener), Bob Karlin (portions of the meeting via phone), David Melski (portions of the meeting via phone), Steve Michell, Jim Moore (secretary), Dan Nagle, Tom Plum (portions of the meeting via phone), Larry Wagoner.
1.3 Procedures for this Meeting (Benito)
We cannot talk about the contents of the TR that is currently undergoing PDTR ballot.
1.4 Approval of previous Minutes [N0179] (Moore)
The minutes were approved as published.
1.5 Review of previous actions items and resolutions, Action Item and Decision Logs
The group reviewed the action items and updated the status of 09-02.
1.6 Approval of Agenda
The group approved the agenda in [N0195] with the addition of the items listed in item 3 of this document.
1.7 Information on Future Meetings
1.7.1 Future Meeting Schedule
The Delft meeting was cancelled because of the balloting schedule. We have rescheduled a meeting for November 2-4 in Santa Cruz, CA. The meeting after that will be in April 26-28 in Padua, Italy. We decide that a meeting in July 2010 is appropriate. Michell offers Canada. We schedule July 19-21 in Canada. Michell will check possibilities for Calgary, Toronto and Quebec.
Later in the meeting, there was discussion of potential conflicts for the date of 2-4 November. The convener will investigate the possibility of holding the meeting on 21-23 October instead.
1.7.2 Future Agenda Items
None were requested.
1.7.3 Future Mailings
- Post meeting mailing
- Pre meeting mailing
We have discontinued the use of pre-meeting and post-meeting mailings. It will be removed from future agendas.
2.1 SC 22
Moore is hoping to convince SC22 to switch to an Excel-based commenting format.
2.2 J3/WG5 (Fortran)
Little has been done on the Fortran annex due to other priorities in the WG. Nagle will attempt to get J3 to take a look at the draft annex in August 2009.
2.3 J4/WG4 (COBOL)
Robert Karlin reported that a proposal for an annex is on the agenda for the Cobol meeting next week. There is a consensus that it is a "good thing to do" but no plan yet.
2.4 WG9 (Ada)
Michell reported that they met in Brest in June. Held a workshop to discuss an annex. They wrote six descriptions and also suggested some changes in the format. They developed a plan to write the rest of them. Will meet in November to follow up.
2.5 J11/WG14 (C)
No report.
2.6 J16/WG21 (C++)
Plum reported that they are meeting this week in Frankfurt. So far, they are not paying any attention to our week, due to other priorities.
2.7a ECMA TC49/TG2 (C#)
No report.
2.7b ECMA TC39 (ECMAScript)
Plum reported that the ECMAScript committee (TC39) is considering a mode that provides stricter compile-time checking. [Subsequent to the meeting, Douglas Crockford, the liaison from TC39, reported that the "use strict" pragma introduced in ES5 removes or reinterprets some of the troublesome features some of the language.] Action Item [Plum]: Locate subject-matter experts on security in ECMAScript.
2.8 MISRA (C)
Benito reported that they have a new chair, Bob Montgomery (UK). They may request Category C liaison status to WG 14 and WG 23.
2.9 MISRA (C++)
(Pygott has not joined the call yet.)
2.10 SPARK
Benito reported that Rod Chapman asked if SPARK could be a language-specific annex. Currently, there is SPARK content in the draft Ada annex. Moore argued that SPARK should have its own annex because it is an Ada-subset. Benito said that other subsets like MISRA should have their own annex. Karlin said that subset annexes could make references to the parent language's annex when the treatment is the same. Plum and Michell suggested that subset annexes should be reviewed by the WG that deals with the parent language.
2.11 MDC (MUMPS)
No report.
2.12 SC7/WG19 (UML)
No report.
2.13 Other Liaison Activities or National body reports
None.
3.0 Proposed changes to format of language-specific annex [N0193]
There was some discussion of the advisability of replacing Annex Letters with the names of the languages. There might be problems with "C", with versions of languages, and with language subsets. The clause currently named "<Language Name>.3" should have a title added: "Programming Language Vulnerabilities". Karlin thinks the 3.x.1 might be superfluous and better explained as part of other parts of the description. (Revisit this point.) Benito suggested that "in language" should be removed from 3.x.4 just as it was removed from 3.x.5. (Revisit this point.)
The following points were made during the discussion of the Ada annex:
When making references to other parts of an annex, should the reference be like D.3.10 or Ada.3.10 or Ada.NAI? Also, the sub-clause numbering? We may need a style guide that provides an easy way for the reader to see that something does not apply. (Maybe something like "Not Applicable" plus a brief paragraph explaining why.) We need to ask drafters to follow the typographical conventions that are explained in the TR. It should be clear from the first few words whether the vulnerability: is not applicable to this language, applicable in some circumstances, or the text in the main document suffices and nothing need be added.
The following points were made during the discussion of the Fortran annex:
The section called "Identification of standards" should not simply be a list of standards. It should do whatever is required to describe the language that is the baseline. In some cases, it might be a standard plus some other documents, or a standard minus the annex that lists deprecated features. It might include some explanation, such as "don't use any features that are undefined".
Avoid making recommendations without laying the basis in the description of the vulnerability.
Maybe we need a few different formats for vulnerability descriptions in the annexes -- a short simple one for cases when the vulnerability is not applicable or is simple and a more complicated one for when extensive description is required.
After comparing the treatments of the different examples, we conclude that the vulnerability descriptions in the language-specific annexes should have the following format:
<language>.<x> Name [3 letter tag]
<language>.<x>.0 Status and history
[Revision history. This section will eventually be removed.]
<language>.<x>.1 Terminology and features
term: An explanation in the form of one or more complete sentences.
[The guidance is that you should consider terms that are in the language standard and which are used in the explanation that follows.]
[In this and other sections, if there is nothing to be explained, simply say "None".]
<language>.<x>.2 Description of vulnerability
[This merges the prior sections for description and mechanism. Examples, both good and bad, are strongly encouraged.]
<language>.<x>.3 Avoiding the vulnerability or mitigating its effects
- An imperative sentence followed by optional additional sentences written in the indicative.
<language>.<x>.4 Implications for standardization
Future standardization efforts should consider:
- Requiring ...
- Adding ...
- Changing ...
- Other verbs ending in "ing"
<language>.<x>.5 Bibliography
[No change from the current]
In those cases where a vulnerability is simply not applicable to the language, the following format should be used:
<language>.<x> Name [3 letter tag]
This vulnerability is not applicable to <language>. [Optionally, an explanation of inapplicability may be added, including qualifications and pointers to other related vulnerabilities that might be present.]
Action Item [Moore]: Put the format in a document, post it, circulate it. (This was done immediately after the meeting as [N0217].
Moore sketched up a strawman proposal for a multi-part document [N0212]. There was some interest in the concept although it was agreed that a decision was premature.
Tom Plum suggested that Robert Seacord might submit a document to be used as a base document for an additional part.
3.1 C language-specific annex [N0200]
Many of the entries come from CERT. Much of the annex was informed by the CERT Wiki. The result of the markup was saved as [N0204]. Overnight, Larry revised the draft to conform to the new format and submitted it as [N0210]. The working group considered the result and provided some markups, saved as [N0215].
3.2 Fortran language-specific annex [N0198]
We reviewed the descriptions up through 3.9 and marked it up. The result was saved as [N0206]. Overnight, Dan prepared a reformatting of a Fortran-specific annex [N0211]. The working group marked it up with some suggestions for improvement, saved as [N0216]. Action [Nagle]: Revise the result in accordance with the new format and circulate it to J3 and WG5.
3.3 Ada language-specific annex [N0199]
The group went through the text and marked specific suggestions into it. The result was saved as [N0205]. Action [Moore]: Post the markup of the annex and send it back to WG9.
There was also a discussion of the inclusion of SPARK material in the Ada annex. Although no formal conclusion was reached, the general opinion was that SPARK should have its own annex rather than share one with Ada. However, in cases where SPARK's treatment is identical to Ada's it could refer to the Ada annex and state that SPARK does the same thing. In cases where the vulnerability doesn't exist in SPARK, the annex could simply state that the vulnerability is not applicable. It was mentioned that language subsets, such as those provided by MISRA, could be handled in the same manner.
3.4 Proposed vulnerability description on namespace issues [N0197]
This was regarded as well-written. No improvements were suggested.
3.5 Proposed vulnerability description on overloading and overriding [N0201]
Some suggestions were made. The result was saved as [N0203]. Action [Moore]: Send the markup to Ploedereder for revision and resubmission.
During the meeting, Michell drafted two additional vulnerability descriptions for the Ada language-specific annex: MEM [N0208]; NMP [N0209]. The working group did a markup of the two proposals and saved them as: MEM [N0213]; NMP [N0214].
5.1 Review of Decisions Reached
Moore paged through the minutes and recapped the decisions.
5.2 Review of Action Items
Moore paged through the minutes and recapped the action items.
The group decided to schedule some telecons:
- 25 August: 9 am PT /12 noon ET, for 3 hours
- 29 September: 9 am PT/12 noon ET, for 3 hours
Moore will set up web/teleconferencing facilities.
Action [Benito]: Check the practicality of moving the November WG23 meeting to 21-23 October. Saturday is also a possibility.
5.3 Thanks to Host
We thanked Steve Michell and SCC for the fine meeting arrangements.