RE: [sarif] Re: Please comment on #125

["Larry Golding \(Comcast\)" <larrygolding@comcast.net>]

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