These minutes were approved at Meeting #8.
- 12 December 2007: 09:00 to 12:00 and 13:30 to 17:00
- 13 December 2007: 09:00 to 12:00 and 13:30 to 17:00
- 14 December 2007: 09:00 to 12:00
Software Engineering Institute 4500 Fifth Avenue Pittsburgh, PA 15213-2612 Room 5300 Note: Visitors will have to check in at the guards desk at the main entrance and get a visitors pass.
- INCITS
- United States of America
Robert C. Seacord
T +1-412-268-7608
F +1-412-268-6989
1.1 Opening Comments (Seacord, Benito)
Robert Seacord welcomed us to the SEI.
1.2 Introduction of Participants/Roll Call
The following persons attended all or part of the meeting:
- John Benito (convener)
- Chad Dougherty (CERT)
- Derek Jones (UK)
- Steve Michell (Canada)
- Jim Moore (secretary)
- Dan Nagle (J3, WG5)
- Tom Plum (WG14, WG21, ECMA TC39/TG2)
- Erhard Ploedereder (WG9, Ada-Europe)
- Clive Pygott (MISRA C++)
- Robert Seacord (CERT)
- David Svoboda (CERT)
- Larry Wagoner (US)
1.3 Procedures for this Meeting (Benito)
The convener reviewed the usual procedures. Everyone can speak. Everyone can participate in straw polls. At this point in the process, we don't need formality.
1.4 Approval of previous Minutes [N0100] (Moore)
The minutes of Meeting #6 were approved.
1.5 Review of previous actions items and resolutions, Action Item and Decision Logs
We updated the action item list. Clive Pygott took a new action item #07-02 to determine if we can get access to draft DO-178C. Jim Moore was given a new action item #07-03 that administratively consolidated three open ones.
1.6 Approval of Agenda [N0103]
Agenda was approved as is. We will add documents as necessary.
1.7 Information on Future Meetings
1.7.1 Future Meeting Schedule of OWGV
We reviewed the schedule for future meetings with the following results:
It was suggested that we might want to coordinate a spring 2009 meeting with the C working group. Steve Michell volunteered to host in Ottawa in June or July 2009.
1.7.2 Future Agenda Items
[None]
1.7.3 Future Mailings
The schedule for mailings was determined as follows:
2.1 SC 22
Benito said there was nothing to report since the last meeting. The resolutions of SC22's most recent plenary meeting have been posted as [N0110].
2.2 J3/WG5 (Fortran)
Nagle said they are nearly finished with their draft and are waiting for the IEEE revision of 754.
2.3 J4/WG4 (COBOL)
No report.
2.4 WG9 (Ada)
Ploedereder reported that they have a relatively low level of activity because of the recent publication of the amendment. They are looking at some fixes and ASIS, a standard for tool representations of programs. OWGV needs to advise WG9 of when work on a language-specific annex would be appropriate.
2.5 J11/WG14 (C)
Plum said there is nothing new to report.
2.6 J16/WG21 (C++)
Plum said there is nothing new to report.
2.7 ECMA TC39/TG2 (C#)
Plum said there is nothing new to report.
2.8 MISRA (C)
Pygott said that Jones, who hasn't arrived yet, may have a report. They plan to start looking at the 1999 C standard.
2.9 MISRA (C++)
Pygott reported that they are 2-3 months away from publishing. The draft is out for peer review, resulting in nearly 1000 comments. They have been dispositioned and the text is nearly completed. It will go to MISRA Board for publication approval in January.
2.10 SPARK
No report.
2.11 MDC (MUMPS)
No report.
2.12 SC7/WG19 (UML)
No report.
2.13 Other Liaison Activities or National body reports
Seacord: CERT is trying to finalize the CERT C Secure Coding guide. They are planning for completion in March and publication in September. They will publish a snapshot with Addison-Wesley but will continue development using the Wiki. Work has begun on a C++ guide.
Pygott: UK Dept of Trade and Industry has set up a Knowledge Transfer Network on computing security.
Because most of the documents expected for this meeting are arriving during the course of the meeting, it was decided that they would be reviewed as they become available.
3.1 Editor's draft of PDTR 24772 [N0106]
This document was not actually reviewed per se. Instead, we reviewed the vulnerability descriptions as noted in the next section.
3.2 Vulnerability descriptions
We reviewed many of the vulnerability descriptions. The remarks are annotated in each description. As a result of discussion, many of the descriptions were assigned to individuals for editing. The table below is a complete list of all of the vulnerability descriptions, grouped according to the individual responsible for editing them:
Benito NMP, RVG, TRJ, EWD Jones TEX, BQF, FAB, EWF, XYX Michell LAV, CCB,XYL, XZH Moore GDL, NZN, CSJ, AMV, IHN, XZM, XYG Nagle XYY, XYF Ploedereder DCM, XYK, XYR Plum HFC, CLL, BRS, NYY, EOJ, SAM, JCW, MTW, XZI Pygott SYM, XYQ, BVQ, XYP Seacord YOW, XYE Wagoner MEM, KOA, PLF, STR, REU, NAI, AJN Unassigned EWR, RST, XYH, XYM, XYN, XYO, XYS, XYT, XYW, XYZ, XZB, XZK, XZL, XZN, XZO, XZP, XZQ, XZR, XZS, XZX OUT of TR XYI, XYJ, XZA 3.3 Larry Wagoner's contribution proposing an organization of the vulnerability descriptions [N0109]
We reviewed Larry Wagoner's contribution. He provided a categorization of the vulnerability descriptions. We discussed whether the outline is used as an outline of a document or used as a tool to generate categories. We decided that the vulnerabilities should be described in a distinct clause as a flat set of sub-sections. However, the proposed outline could be used as a distinct clause providing a topical outline that "points" to the various descriptions. The document is annotated with the result logged as [N0112]
3.4 Tom Plum's contribution regarding undefined behaviour [N0104]
Tom Plum introduced his paper urging that undefined behaviour be distinguished as "critical" or "non-critical". If language designers were to apply this distinction, then we would be able to use the distinction in our TR. It was decided that vulnerability description REU (termination) should incorporate some of the concepts.
3.5 Barry Tauber's example of mapping MISRA C rules to Cobol [N0105]
We briefly reviewed Barry Tauber's paper and will retain it for eventual use in developing a language-specific annex for Cobol.
3.6 Clive Pygott's (UK) proposal for additons to the TR [N0108]
We reviewed Clyve's document and decided that the text suggested for clause 1.4 should be included. Also the editors should add some words about compiler writers and tool vendors. The document's proposal for a vulnerability on "order of evaluation and initialization" was referred to the drafter of vulnerability SAM. The document's proposal for a vulnerability on "Dead code and unspecified functionality" will be merged into XYQ. However, there will be a distinct vulnerability description for "unspecified functionality", BVQ, focusing on the language features used to introduce such code.
3.7 Report of editor of TR 24772 [N0107]
We reviewed the editor's report. He called our attention to the section labeled "Comments not applied to the base document". These are comments from Roger Scowen that were submitted in hard copy form as a markup of the draft that was registered with SC22. The editor resolved the easy comments himself and applied them to the draft. The 21 comments listed in the editor's report are items that the editor decided should be discussed by the group. The following decisions are made:
- 1. Defer a decision on this. The politics of identifying languages may be difficult.
- 2. Agree. Operating systems or programming environments used in examples should be identified.
- 3. Agree. Subclause 1.1 should be rewritten as a paragraph.
- 4. Agree. Change the title to "Applicable Language Characteristics" but make sure that all descriptions include the sentence, "This vulnerability description is intended to be applicable to languages with the following characteristics:"
- 5. Agree in principle. Material like this should go into Clause 5. We are already developing text on concepts like "unspecified behaviour". We should do this for terminology that is cross-cutting, general, otherwise judged to be confusing. Differing terminology related to specific vulnerabilities would be described in language-dependent annexes.
- 6. Agree. Derek will develop an example for 5.2, "Issues arising from human cognitive limitations".
- 7. Agree. Rewrite XYG in terms of "formal parameter" and "actual argument" as well as any others dealing with this subject.
- 8. (No comment had this number.)
- 9. OBE
- 10. Agree. Will revise accordingly.
- 11. Agree in principle. Will remove references to commercial products.
- 12. Agree in principle. Will remove references to commercial products.
- 13. Agree.
- 14. Agree.
- 15. Agree.
- 16. Agree.
- 17. Agree in principle. Will revise XYX to deal with the issue.
- 18. Agree will revise XZI.
- 19. Agree in principle. will revise XZH
- 20. We decide to defer to the editor.
- 21. Agree in principle. We will revise XYP.
During a discussion of the application of the TR to machine-generated code, Robert Seacord accepted Action Item #07-01 to propose a set of categories ranging from hand-written to tool-generated in order to provide a lexicon for discussion. [Prior to the end of the meeting, he provided document N0114.]
We discussed how to move forward. We decided that all revised descriptions must be submitted by 14 February (Valentine's Day). We will use Larry's submission, annotated as [N0112] as the basis of a topical outline that will list the vulnerabilities and also indicate who is responsible for each one of them. We decided to continue using the vulnerability directory as the single source of the descriptions as they evolve. In the pre-meeting mailing, we should distribute a list of descriptions that should be reviewed and discussed. Moore should compose a spreadsheet for collecting comments on vulnerabilities (action item #07-05). (Immediately, after the meeting, Moore provided this as document [N0115].) So, the review period will be the time between 14 Feb and the pre-meeting mailing on 22 Mar.
So the summary schedule is as shown below:
- Mon Dec 17: Vulnerabilities directory is uploaded with meeting results. Moore distributes commenting spreadsheet.
- Dec 18-Feb 14: Each person assigned a vulnerability revises the description and sends it to Moore.
- Feb 14-Mar 21: Participants review descriptions and create spreadsheets containing comments. They are sent to Moore by March 21.
- Mar 22: Moore consolidates spreadsheets and redistributes as part of the pre-meeting package.
- At the Amsterdam meeting, we will review the vulnerability descriptions and the consolidated comments. To the extent possible, we will fix the descriptions on the spot and mark vulnerabilities as "good enough" for formal balloting.
5.1 Review of Decisions Reached
[They are summarized in the minutes, the vulnerability descriptions, and the logs.]
5.2 Formal Vote on Resolutions
[There were no resolutions.]
5.3 Review of Action Items
Five action items #07-01 through #07-05 were added to the action item log.
5.4 Thanks to Host
We thanked Seacord for the hosting.
The meeting adjourned at roughly 12:45 pm on 14 December 2007.