OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sarif message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Raw minutes of SARIF #5 meeting 2017-10-25


[18:39] Stefan: Voting Members: 14 of 19 (73%) (used for quorum calculation)
[18:39] Stefan: Changed voting member status noted later
[18:40] Stefan: 1.3 Procedures for this meeting (Co-Chair Keaton)
[18:40] Stefan: 1.4 Approval of agenda (Co-Chair Keaton)
URL = https://www.oasis-open.org/committees/download.php/61861/agenda_20171025.html
[18:40] Stefan: Michael moves to approve the agenda, stefan seconds
[18:40] Stefan: no discussion, no objections
[18:41] Stefan: agenda is adopted
[18:41] Stefan: 1.5 Approval of previous minutes [Minutes of 2017-09-27 Meeting#3] (Co-Chair Keaton)
URL = https://www.oasis-open.org/committees/download.php/61800/sarif-minutes-20171011-meeting-4.html
[18:41] Stefan: Michael fanning moves to approve the minutes, laurence seconds
[18:41] Stefan: no discussion, no objections, approved unchanged as published
[18:41] Stefan: 1.6 Review of action items and resolutions (Secretary Hagen)
  - Officers to create the meetings for the agreed meeting times
Status: Done
  - Michael to create a new issue to continue the conversation on namespaces and tool level <placeholder for better term>
Status: Done
Details: #59 - Consider a tool validation or 'selectivity' annotation
URL: https://github.com/oasis-tcs/sarif-spec/issues/59
[18:42] Stefan: 1.7 Identification of SARIF TC voting members (Co-Chair Cartey)
1.7.1 Prospective members attending their first meeting
1.7.2 Members attaining voting rights at the end of this meeting
None
1.7.3 Members losing voting rights if they have not joined this meeting by the time it ends
Mr. Chris Wysopal group role will be changed to Member
1.7.4 Members who previously lost voting rights who are attending this meeting
None
1.7.5 Members who have declared a leave of absence
None
[18:43] Stefan: Delayed
[18:44] Stefan: 2. Future Meetings
  2.1 Future meeting schedule (Co-Chair Keaton)
Teleconferences (Wednesdays at 09:30 Pacific):
  November 8
  November 29
  December 13
  January 10
Face-to-face meeting
  January 22-23 (tentative)
[18:44] Stefan: 3. Continuation of last meeting's discussions (Co-Editor Fanning)
  3.1 Announcements
[18:44] Stefan: Michael: Editors went through the issues
[18:45] Stefan: Michael: Wants to discuss tag additions in todays meeting
[18:45] Stefan: Michael: .. Also namespace tags coming from other sources
[18:46] Stefan: Michael: Property bag and data association with tags is slightly different (tags is a reserved key in a property bag)
[18:46] Stefan: Michael: Informs the group that there is some spec content and the editors deem ready to agree upon
[18:47] Stefan: Michael: Encourages everyone folows along with the pull request language
[18:48] Stefan: Laurence: A change draft in document/changedrafts is created with a special naming convention (@Laurence please add specifics)
[18:50] Stefan: Laurence: Further explains some procedure for the git workflow, like pull change push
[18:50] Stefan: @Laurence: Please copy to *this* chat window for the minutes. Thank you
[18:51] Stefan: 3.2 Final disposition of items begun at last meeting
3.2.1 Consider adding namespaces to tags #56 https://github.com/oasis-tcs/sarif-spec/issues/56
3.2.2 Should we allow formatting in messages?
  - # 33 - https://github.com/oasis-tcs/sarif-spec/issues/33
[18:51] Stefan: - # 57 - https://github.com/oasis-tcs/sarif-spec/issues/57
  - # 61 - https://github.com/oasis-tcs/sarif-spec/issues/61
[18:54] Stefan: Michael: Summarizes the current status of evaluation and alternative proposals for link embedding
[18:55] Stefan: Michael asks if we can drop the markdown support, or objections?
[18:56] Stefan: Laurence: supports this. He wants to state, that JSON Schema might support the message format option in the future via this mechanism
[18:58] Stefan: Sample will be inserted
[18:58] Laurence J. Golding: Example of proposed embedded link format from Change Draft:
[18:58] Stefan: Paul Anderson is not much in favor of dropping
[18:58] Laurence J. Golding: "results": [
  {
    "ruleId": "JS1012",
    "fullMessage": "Tainted data was introduced [here](Input.js(15,9,16,13))."
  }
]
[18:58] Stefan: @Laurence: Thanks
[18:59] Stefan: Paul Anderson would like to retain some formating aspects, to not lose benefit offered in tools (readability)
[19:01] Stefan: Michael tries to balance benefits and risks for other users (enforcement to support)
[19:02] Stefan: Paul Anderson notes, that he would have to write an exporter twice (for formated and unformated one)
[19:04] Stefan: All discuss the issue
[19:07] Stefan: Paul states, that at least keeping bullet points would leave him less unhappy
[19:10] Stefan: Speaker queue has Laurence and Jim in that order
[19:12] Stefan: Laurence reminds everyone, that markdown was also designed the way it is, as it looks ok unrendered and asks for additional details from Pauls use cases
[19:13] Stefan: Paul had a custom XML dialect for the markup (like subscripts etc.) and he would be able to share
[19:13] Stefan: Michael would be interested in seeing this dialect
[19:14] Stefan: Jim thinks some kind of markup would be useful
[19:14] Stefan: Jim mentions, that this should allow easy separation of categories
[19:15] Stefan: Speaker queue has Yekatarina and Laurence in that order
[19:16] Stefan: All discuss
[19:17] Stefan: Speaker Queue has Yekatarina
[19:18] Stefan: Speaker queue has Yekatarina and Laurence in that order
[19:22] Stefan: Jim would like to have a three level info triple as code (up to 8 characters long, than about 100 characters long than for e.g. beginner programmer unconstrained length info like e.g. 2 pages rendered on SQL injection ... so a power analyst can easily go over thousands of results, without being distracted by repetitive text
[19:23] Stefan: All continue to discuss in the light of SARIF design principles
[19:23] Stefan: Speaker Queue has Yekatarina
[19:26] Stefan: Yekatarina explains, that fortify does similar things to what Paul Anderson described on his tool set. Both have very limited markup, like formatting bold italics etc and links. They even do this for the abstract with replacement tags to make it easier to use
[19:27] Laurence J. Golding: Yekaterina: Fortify also has custom markup (limited set of HTML tags) together with "placeholders" (variables, links)
[19:27] Stefan: Michael kindly requests if Yekatarina could share some documentation (esp. on the placeholders) so we can consider this in analysis
[19:27] Stefan: All discuss
[19:28] Stefan: Michael wonders, if a fairly substantive report that uses the full set of markup tags from Yekatarina and Paul so the TC can analyse and make suggestiosn for a subset
[19:29] Stefan: Paul substitution is done on their tool when the warning is rendered, right? Yekatarina approves this understanding
[19:30] Stefan: Speaker queue has Laurence
[19:33] Stefan: All agree, that display of formatted info based on SARIF will always be harder than in the native tool
[19:34] Stefan: Laurence: if linkback from sarif to native source report would be possible, that would be optimal
[19:34] Stefan: Laurence emphasizes, that sarif does not mix up message and codeflow, but keeps this separate
[19:37] Stefan: Michael and Laurence suggest to showcase a visual studio plugin that works on message presentation of that "stuff" (scribe only crude sketching)
[19:38] [Co-Chair] David Keaton: https://github.com/oasis-tcs/sarif-spec/issues/57
[19:40] Stefan: All discuss the region issue
[19:41] Stefan: Laurence suggests to discuss offline with Michael to reach consensus before discussing in TC
[19:41] Laurence J. Golding: https://github.com/oasis-tcs/sarif-spec/blob/master/Documents/ChangeDrafts/sarif-v1.0-issue-57-61-embedded-link-and-region-specifier.docx
[19:41] Stefan: Action on Michael and Laurence to discuss above link target
[19:42] Stefan: All discuss
[19:43] Stefan: Jim enters Speaker Queueu
[19:44] Stefan: Jim asks, if SARIF already has a list of locations?
[19:44] Stefan: Laurence: A result object specifies a single location where detected, but the SARIF result may list all locations of that finding (e.g. partial class)
[19:44] Stefan: Laurence mentions another sort of mutliple location
[19:45] Stefan: Laurence: Third zero or more related locations may be stated
[19:45] Stefan: Jim referred to all of these three kinds
[19:46] Stefan: Michael: There is a unique ID concept in SARIF for this: it is the URL
[19:46] Laurence J. Golding: Stefan: The second kind of location was code flows -- a sequence of locations that the tool steps through to detect the result.
[19:46] Stefan: Mihcael: The rest of the locations could refer to that.
[19:47] Stefan: @Laurence: Thanks
[19:48] Stefan: All discuss on how a consumer has an easier task, when providing a direct URL instead of a reference e.g. 701 and then look that up.
[19:51] Stefan: Discussion continues on embedded links versus related locations concept
[19:54] Paul Anderson: Sorry everyone! I have to drop off early. Thanks for a great discusssion.
[19:57] Stefan: Michael summarizes his understanding of possibilities of current proposal as possibly allowing to remove related regions if users fall in love with URI everywhere ...
[19:57] Stefan: Laurence thinks this should not indicate removal of related regions
[19:58] Stefan: Jim also thinks these remain useful
[19:58] Stefan: Michael dislikes about related regions, as it is not clear where to anchor the referring / relations in all cases
[19:58] Stefan: all discuss
[19:59] Stefan: - # 61 - https://github.com/oasis-tcs/sarif-spec/issues/61
[20:00] Stefan: Laurence suggests to construct a parallel document with a competing proposal
[20:01] Stefan: Michael relates the current discussion to  3.4 Consider restructuring SARIF to be location, not results-focused # 55 https://github.com/oasis-tcs/sarif-spec/issues/55
[20:02] Stefan: Take feedback and make a finished proposal for URL protocol to add a fragemtn for a region
[20:02] Stefan: Alternatively add a fragment to target locations
[20:03] Stefan: Paul and Yekatarina to provide samples for documenting their use of markup
[20:03] Stefan: 3.3 Consider adding 'rank' or 'probability' property # 58 https://github.com/oasis-tcs/sarif-spec/issues/58
[20:05] Stefan: Michael summarizes the issue
[20:07] Stefan: Jim has one concern for rank info go into the property bag, might lose some info for context
[20:07] Stefan: Laurence enters Speaker queueu
[20:08] Stefan: Michael suggests that we could use namespace tags as prefix to resolve collisions, Jim is in fear of
[20:09] Stefan: Michael thinks, that if one can map rank into 0 or 1 value, this could lead to inclusion of the proposal
[20:11] Stefan: Laurence thinks, it is not good to put a reserved property name into the spec, when it is well defined, as this should end up as a first class element.
[20:11] Stefan: Michael confirms, that rank is strictly for sorting, not for certainty
[20:12] Stefan: Mel enters the Speaker Queue
[20:13] Stefan: All discuss on recoverable certain semantics when aggregating multi tool results
[20:15] Laurence J. Golding: https://github.com/oasis-tcs/sarif-spec/issues/48
[20:16] Stefan: Summary: "End-to-end results management concepts"
[20:19] Stefan: Mel rank and probability are not of much use in this context, but more confidence (from the tool)
[20:21] Stefan: 4. Other Business
[20:22] Stefan: 5. Resolutions and Decisions reached (by 10 minutes prior to scheduled meeting end)
5.1 End debate of other issues by 10 minutes prior to scheduled meeting end and follow the agenda from this point (Co-Chair Keaton)
5.2 Review of Decisions Reached (Secretary Hagen)
A suggested workflow for comments on changed docs in specific folder by pull, edit, push cycle
[20:22] Stefan: 5.3 Review of Action Items (Secretary Hagen)
1) Action on Michael and Laurence to prepare offline consensus based on proposal embedded in https://github.com/oasis-tcs/sarif-spec/blob/master/Documents/ChangeDrafts/sarif-v1.0-issue-57-61-embedded-link-and-region-specifier.docx
2) Editors to take the provided feedback and make a finished proposal for URL protocol to add a fragemtn for a region
3) Editors to in addition to propose how to alternatively add a fragment to target locations proposal
4) Paul Anderson and Yekatarina to provide samples for documenting their use of markup
[20:24] Stefan: Michael alternate proposals for region identifier
[20:24] Stefan: 6. Next Meeting
  November 08, 2017 / 09:30-11:30 PT / 17:30-19:30 UTC
[20:24] Stefan: 7. Adjournment
[20:24] Stefan: Stefan moves to adjourn
[20:24] Stefan: Michael seconds
[20:25] Stefan: No discussion, no objection
[20:25] Stefan: Meeting adjourned by chair


# Meeting Attendees 

## Company                                    Name ascending        Role

GrammaTech, Inc.                              Paul Anderson         Voting Member
SWAMP                                         Vamshi Basupalli      Voting Member
Microsoft                                     Sunny Chatterjee      Voting Member
Microsoft                                     Michael Fanning       Voting Member
Individual                                    Laurence Golding      Voting Member
Individual                                    Stefan Hagen          Secretary
Micro Focus                                   Larry Hines           Voting Member
Individual                                    David Keaton          Chair
SWAMP                                         Jim Kupsch            Voting Member
Synopsys                                      Mel Llaguno           Voting Member
Security Compass                              Pooya Mehregan        Member
Micro Focus                                   Yekaterina O'Neil     Voting Member
NIST                                          Vadim Okun            Observer
Microsoft                                     Andrew Pardoe         Voting Member
Code Dx, Inc.                                 Ken Prole             Voting Member
Kestrel Technology                            Henny Sipma           Voting Member


# Meeting Statistics

Quorum rule:                             51% of voting members
Achieved quorum:                         yes
Individual Attendance Observing Members:  1 of  9 (11%) 
Contributing Members:                    15 of 33 (45%)
Voting Members:                          14 of 19 (73%) (used for quorum calculation)
Company Attendance  Observing Companies:  1 of  5 (20%)
Contributing Companies:                   9 of 20 (45%)
Voting Companies:                         8 of 11 (72%) 

# Roster changes based on participation status of this meeting effective after the meeting:

Mr. Chris Wysopal group role has been changed to Member






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]