- 28 June 2010: 09:00 to 12:00 and 13:30 to 17:00
- 29 June 2010: 09:00 to 12:00 and 13:30 to 17:00
- 30 June 2010: 09:00 to 12:00
Royal Kona Resort
75-5852 Alii Drive
Kailua-Kona, HI 96740 USA
Phone: +1-808-329-3111 or +1-800-919-8333
FAX: +1-808-329-9532
Dial-in number: 1-703-983-6338
Web URL: http://audioconference.mitre.org
Meeting number: 060648
Meeting password: 06061948The web/tele-meeting is booked from 2 pm - 12 midnight ET, which corresponds to 8 am - 6 pm Kona time. Interested persons should look at the agenda to determine the actual time of the meeting.
Thomas Plum
Plum Hall Inc
3 Waihona Box 44610
Kamuela HI 96743
E-mail: [email protected]
Phone: +1-808-882-1255
Fax: +1-808-882-1556
1.1 Opening Comments (Plum, Benito)
Tom Plum welcomed us to Kona. The convener will hold the meeting room key and lock it during lunch and any other long breaks. The convener asked if the meeting hours are OK with everyone. All agreed that they are OK.
1.2 Introduction of Participants/Roll Call
Attendees included Tom Plum, Larry Wagoner, Steve Michell, John Benito, and Jim Moore. Bob Karlin and Clive Pygott joined by phone.
1.3 Procedures for this Meeting (Benito)
The usual -- everyone can talk. There are no votes.
1.4 Approval of previous Minutes [N0248] (Moore)
Minutes were approved.
1.5 Review of previous actions items and resolutions, Action Item and Decision Logs
Status was reviewed and updated.
1.6 Approval of Agenda [N0246]
Agenda was approved with changes to include the documents listed under item 3. If we have time, Steve will also go over some draft concurrency vulnerabilities with us.
1.7 Information on Future Meetings
1.7.1 Future Meeting Schedule
- Meeting #15: 15 -17 Sept. 2010, Ottawa, Canada (SC22 plenary meeting is 13-14 Sep; on 15 Sep, Sally Seitz will teach a course on the new directives.)
- Meeting #16: 14-16 Dec 2010, San Diego, CA
- Meeting #17: INCITS now has two meeting rooms. Either would accommodate our group. That would be a possibility. WG21 will meetin in Madrid but their meeting is not firm yet. WG14 will probably meet in Florence, IT and would be an excellent choice for colocation. Florence is the favored alternative.
- Meeting #18: June 18-20, colocated with WG9 in Edinburgh.
- Meeting #19: September 2011, Copenhagen, with SC 22, dates are still unclear.
- Meeting #20: December 2011, tentative Washington, DC. Action item #14-01: Jim will check if it can be hosted in McLean.
1.7.2 Future Agenda Items
After the first draft of the second edition is prepared, the working group will reconsider the comments from MISRA L [N0250].
2.1 SC 22
Steve reviewed the new JTC 1 procedures. Each of the parents, ISO and IEC, have their own supplements to the ISO/IEC directives. Historically, JTC 1 has directives that supplant the ISO/IEC directives. ISO and IEC have found several troublesome aspects of this approach and have required JTC 1 to harmonize their directives with the ISO/IEC directives. FCD is an issue. Fast-tracks are also an issue. Also, PAS.
So a committee has been working on writing a JTC 1 supplement to the ISO/IEC directives. A problem is that the supplement is approved by the parents, hence we will lose control, so we will also have a number of "standing documents". The net result is the following hierarchy of documents:
- ISO/IEC directives
- JTC 1 supplement
- A bunch of standing documents, including:
- Electronic meetings
- Registration authorities
- PAS
- Maintenance processes
- Normative references
- Meetings
- Liaisons
- Electronic documents
- Conformity assessment
- APIs
- Advisory and ad hoc groups
Sally Seitz has been given the task of creating a single web page with links to the various documents.
Differences include:
- Type 1 and type 2 TRs are now Technical Specifications. Only a type 3 TR remains as a Technical Report.
- A PAS does not become an IS until its first revision. PAS and fast-track are now better integrated.
- Reduce the ability of ballot resolution meetings to overturn consensus reached in balloting. So there will always be an FDIS, even on a fast-track.
- CD ballots can be two, three or four months in duration.
- There is no FCD ballot. Instead there is a DIS (5 months) followed by a FDIS (2 months). The FDIS is not needed if there are no negative votes and no significant comment.
- TRs and TSs continue with the current process. Amendments and Corrigenda also continue the current process.
2.2 PL22.3/WG5 (Fortran)
We have not had a recent report.
2.3 PL22.4/WG4 (COBOL)
Bob reports that he may have a candidate to work on a Cobol annex.
2.4 WG9 (Ada)
Steve reported that a draft Ada annex [N0258] has been submitted and will be discussed later in this meeting. A proposed SPARK annex has been referred back to Rod Chapman for additional work.
2.5 PL22.11/WG14 (C)
Tom reported that WG14 had a difficult meeting in Florence, IT. Many members were unable to attend because of the disruption in air travel. A make-up meeting was conducted in Boulder the next month. They did not look at the draft C annex that Larry had prepared.
2.6 PL22.16/WG21 (C++)
Tom believes that the perceived marketplace of C++ is not demanding vulnerability catalogs, hence WG21 is relatively uninterested in the work. The convener took action item #14-02 to talk with Bjarne Stroustrup and Herb Sutter about possibilities for moving forward.
2.7 Ecma International, TC49/TG2 (C#)
The response to our liaison request is that they would be willing to review material.
2.8 Ecma International, TC39 (ECMAScript)
The response to our liaison request is that there is interest but little willingness to undertake drafting an annex.
2.9 MISRA (C)
No report
2.10 MISRA (C++)
No report
2.11 MISRA L (MISRA L)
No report
2.12 SPARK
(See the WG9 report under 2.4.) Also, the following came from Rod Chapman via email:
At the recent HRG and WG9 meetings in Valencia, the focus was very much on getting the Ada Annex finished first, as you have seen.
HRG did also review and discuss the SPARK Annex, but requested a few actions from me to strengthen the introduction and to improve the wording of a few sections. At the moment, I have a deadline of 15th July to re-submit the SPARK Annex to WG9 for their consideration, so we hope to have it ready in time for the WG23 meeting in September.
2.13 MDC (MUMPS)
No report
2.14 SC7/WG19 (UML)
No report
2.15 Other Liaison Activities or National body reports
No report
3.1 N0253: Draft New Work Item Proposal: Software Code Signing [docx, pdf], contributed by Larry Wagoner
A digression ... The OWASP group has written input validation functions that may be useful for developers using various languages. Larry wonders what the appropriate home might be for a standardization effort. There was sentiment that this was good work and that WG23 might be a good home for the work.
Larry has connected with the SC7 folks who are standardizing code tagging methods for software asset management.
We marked up the draft with minor revisions. (The result is document [N0265]. We gave the convener action item #14-03 to table the proposal for consideration at the plenary meeting of SC 22.
3.2 N0258: Draft language-specific annex for Ada, contributed by WG 9 [pdf]
(See item 3.3 below.)
3.3 N0259: Revised draft language-specific annex for C, contributed by LarryWagoner [docx, pdf]
We began discussing the Ada annex. Later in the discussion, we found it helpful to go back and forth between the two annexes, comparing them "horizontally" in an effort to gain insight.
Definitions appear in two places in the Ada annex: at the front of the annex; within each individual description.
The definitions redefine some of the terms in the document, e.g "implementation defined".
Karlin suggests a rule: A definition should appear in an annex only if it has a meaning specific to the language. Otherwise it should appear in the main document.
The list of terms does not explain relationships to more general terms. For example, the definition of task does not say that it is similar to a thread.
Steve thinks that the definition of "unsafe programming" is too short. For example, it might explain that compiler switches can be used to turn off range checking. It might be appropriate to add anonymous access types also.
Steve suggests that we might want to remove "Obscure Language Features" from our document, because none of the languages are admitting to having them. Jim mentioned that such a feature in Ada might be that exceptions don't propagate out of tasks. That is not specifically listed in the Ada annex. Tom suggests that we might be asking the wrong people, we should ask the persons who experience the problems in real life.
Maybe we should rename the vulnerability as "Frequently Misused Language Features".
The explanation of "identifier" at the top of NAI is mysterious. Throughout the description, "name" and "identifier" seem to be used interchangeably. It would be appropriate to stick to one term.
We noted that the Ada description of AJN and the C description say essentially the same thing but in different tones. After examination, we reach the conclusion that AJN should be moved to Clause 7 and removed from the language-dependent annexes.
In the Ada annex, XYH does not mention Unchecked_Deallocation amd pragma suppress. It should either mention that possibility or the section on "unchecked" stuff in the beginning of the annex should be generalized and strengthened.
We discuss a possible new vulnerability description called "Performance Optimization Issues". These include suppressing checks in languages where it's unnecessary and changing compiler optimization settings in the delivered version of code. Also mention the case where compiler optimization clashes with expected undefined behaviour (such as an expectation of wrap-around on overflow).
Larry suggests a vulnerability called "Lack of Authoritative Specification" for languages where there is really no reference to describe what the behaviour should be.
For vulnerabilities that are not applicable, the subsection headings should be omitted.
We looked at vulnerability LAV in both the C and Ada annexes. It was noted that the Ada description is wordy and leads a reader to suspect that Ada is in a worse situation than it actually is. Also it was suggested that the C annex is written in a style that places the "bottom line" in the beginning of the description while the Ada treatment is more scholarly. We want to respect the material that people contribute and we don't want to keep sending it back for rewrite.
It was generally agreed that we need summary material that provides brief descriptions of each vulnerability in a uniform style. Jim suggested putting such a summary at the beginning of each vulnerability description. Steve suggested putting the summaries in a tabular format so that languages could be easily compared. It was decided that Steve's approach was more promising and that we should try it out based on the two draft annexes that we have in hand.
Steve and Jim took action items, #14-04 and #14-05, to draft tables capturing summary information.
Jim mentioned that the important aspect of the table would be to identify risks. Bob said that he wants two things: whether the vulnerability applies to the language; and whether the language provides techniques for mitigation. Steve suggested that the availability of tooling would also be relevant.
Bob will take action item #14-06 to select a few of the Ada vulnerabilities and propose rewrites of them in newspaper style. He will track the time it requires to do this.
3.4 N0260: ISO/IEC JTC 1/SC 27 N8780, 1st CD 29147, Information technology -- Security techniques – Vulnerability disclosure [pdf]
The convener believes that we need to pay attention to the definitions in this document. Some overlap with ours and we should consider if we need to change them.
3.5 N0262: Request for approval of free availability for ISO/IEC TR 24772, Information Technology - Programming Languages - Guidance to Avoiding Vulnerabilities in Programming Languages through Language Selection and Use [docx, pdf]
We marked up the draft with revisions. (The result is document [N0264].) We gave the convener action item #14-07 to table a proposal for consideration at the plenary meeting of SC 22.
3.6 N0263: P.M. Conmy, C. Pygott, I Bate, VHDL Guidance for Safe and Certifiable FPGA Design, Contributed by Clive Pygott [zip].
(This paper arrived during the meeting.).
We discuss possible changes for the next edition of the TR.
John takes action item #14-08 to prepare a redline illustrating the following:
He will consider the language annexes as well as the body of the document.
Clive takes action item #14-09 to prepare a redline illustrating:
Jim takes action item #14-10 to prepare a redline of how the front matter should be slimmed down. This would include:
5.1 Review of Decisions Reached
The only decisions were action items. See 5.2.
5.2 Review of Action Items
Jim reviewed the action items. In addition, John and Larry took an action item to review the C annex again.
5.3 Thanks to Host
We thanked Tom Plum of Plum Hall for his generous hospitality.
We adjourned at 11:00 am on Wednesday, 30 June.