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: Re: [sarif] Re: Please comment on #125


I like it :).

On 04/10/2018 02:26 PM, Larry Golding (Comcast) wrote:
I see. So the `file` object might have a new property `originalFileLocation` in addition to its existing `fileLocation` property. [If that's not what you're proposing, stop reading now and correct me!]

So we have two different proposals:

Your proposal introduces a new property `file.originalFileLocation`. It relies on intervention from the build monitoring system to move the files around, and to populate `file.originalLocation`. It does _not_ require potentially large file contents to be embedded in the SARIF log file.

My proposal (well, I suppose it's actually Michael's 😊) does not require a new property, but it still relies on the build monitoring system to be aware of files that might be overwritten, so that it can create the per-file-version uriBaseIds like "generated-1". (This is not something we'd want each tool to have to worry about.) And, it embeds potentially large file contents in the SARIF log file.

For that last reason, I like your proposal better. What do the rest of you think?

Larry

-----Original Message-----
From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of James A. Kupsch
Sent: Tuesday, April 10, 2018 12:15 PM
To: Larry Golding (Comcast) <larrygolding@comcast.net>; 'Michael Fanning' <Michael.Fanning@microsoft.com>; sarif@lists.oasis-open.org
Subject: Re: [sarif] Re: Please comment on #125

As part of build monitoring, I might capture each file that is accessed by a build commands and store them in a file system with a unique name, while recording their original path.  I could then create an archive of this directory or store this directory somewhere.  Now I have files with the contents, but they are not located at the original path.  It might be nice to be able to refer these locations instead of (or in addition
to) storing the contents in-line in the fileContents value.

Jim


On 04/10/2018 01:48 PM, Larry Golding (Comcast) wrote:
I'm not sure what you mean by that. In the example below, the "path to the file when captured" is given by a combination of run.originalUriBaseIds and result.location.physicalLocation.fileLocation.uri. And the "copy of the file contents" is in run.files.

Can you tell me, in terms of a modification to the sample JSON code I sent, what you're suggesting?

Larry

-----Original Message-----
From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On
Behalf Of James A. Kupsch
Sent: Tuesday, April 10, 2018 11:31 AM
To: Larry Golding (Comcast) <larrygolding@comcast.net>; 'Michael
Fanning' <Michael.Fanning@microsoft.com>; sarif@lists.oasis-open.org
Subject: [sarif] Re: Please comment on #125

This scenario was mentioned by Paul at the in person meeting.  Maybe there should be a separation of the path to the file when captured and the path to a copy of the file contents.

Jim


On 04/10/2018 11:41 AM, Larry Golding (Comcast) wrote:
I see!  A SARIF producer enables consumers to access previous
versions of an overwritten file not just by /mentioning/ each version
in the run.files dictionary, but by /persisting their contents/
there. It seems so obvious now 😊 I can write the text for this now.

Editorial consideration: Explaining this, including an example, will
take up a medium amount of space. And it’s not obvious where it does
in the spec (in the run.files section? In the uriBaseId section?). So
I propose to add a new non-normative Appendix to explain this corner case.

Example below. Note the interplay between originalUriBaseIds,
result.location, and the property names in run.files. It’s actually
kind of elegant. It gives me faith in our format that it can
represent this corner case in such a natural way.

Larry

{                                      # A run object

     "originalUriBaseIds": {

       "generated-1": "file:///dev-machine/c:/project/out/obj",

       "generated-2": "file:///dev-machine/c:/project/out/obj"

     },

     "results": [

       {

         "ruleId": "CA4567",

         "location": {

           "physicalLocation": {

             "fileLocation": {

               "uri": "MainWindow.xaml.g.cs",

               "uriBaseId": "generated-1"

             },

             "region": {

               "startLine": 42

             }

           }

         }

       }

     ],

     "files": {

       "#generated-1#MainWindow.xaml.g.cs": {

         "fileContent": {                 # THIS IS WHAT MAKES IT WORK

           "text": "..."

         }

       },

       "#generated-2#MainWindow.xaml.g.cs": {

         "fileContent": {

           "text": "..."

         }

       }

     }

}

*From:* Michael Fanning <Michael.Fanning@microsoft.com>
*Sent:* Monday, April 9, 2018 7:59 PM
*To:* Larry Golding (Comcast) <larrygolding@comcast.net>; 'James A.
Kupsch' <kupsch@cs.wisc.edu>; sarif@lists.oasis-open.org
*Subject:* RE: Please comment on #125

I’ve thought about this issue a bit. We should be thinking about an
analysis that provides a hit in any generated file that isn’t under
source control. For example, a generated XAML code-behind file. The
corner case covers something even more problematic, a single analysis
run where generated files are, for example, overwritten on a
per-project basis (to a common location in some build intermediates
folder). To answer your questions:

   1. This isn’t tool specific, it relates to scan targets which are
      themselves generated content not under source control (and which are
      fluid/overwritten even while some larger build analysis is
taking
place)  2. The file is a valid scan target, whatever that means. A PCH file or
      other intermediate. A header file that is generated by some perl
      script. Etc.
   3. Producers SHOULD persist all files to run.files that aren’t managed
      by a version control system. This is just good general guidance.
   4. It may be necessary to represent multiple versions of this
      re-written file in the run.files dictionary, if multiple results
      instances exist that point to different versions of the generated
      content.
   5. Ditto, a viewer will need to access any version of the file
      referenced by any result.

*From:* Larry Golding (Comcast) <larrygolding@comcast.net
<mailto:larrygolding@comcast.net>>
*Sent:* Friday, April 6, 2018 2:31 PM
*To:* Michael Fanning <Michael.Fanning@microsoft.com
<mailto:Michael.Fanning@microsoft.com>>; 'James A. Kupsch'
<kupsch@cs.wisc.edu <mailto:kupsch@cs.wisc.edu>>;
sarif@lists.oasis-open.org <mailto:sarif@lists.oasis-open.org>
*Subject:* Please comment on #125

#125
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Foasis-tcs%2Fsarif-spec%2Fissues%2F125&data=02%7C01%7Cmichael.fanning%40microsoft.com%7C2edd19213dba40390cf308d59c05ff3a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636586471924348658&sdata=pdOhg5OiBHMyKm47iFLpSgTZKieHrgx2n5G3ygdPqdA%3D&reserved=0>:
Address corner case for generated files in run.files dictionary

This is the scenario where the same physical file is re-written in
the course of an analysis. Please see my comments in the issue. What
is the scenario here? – that is:

    * What tool is involved?
    * What is the nature of the file that’s being re-written?
    * Is it necessary to represent this file in the run.files dictionary?
    * Is it necessary to represent /multiple versions/ of this re-written
      file in the run.files dictionary?
    * Would a viewer need access to /any version of this file except the
      last one written/?

Thanks,

Larr


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




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