When a security issue is discovered in an add-on submission, a report in .sarif format is produced. Then, a comment is posted instructing the
submitter to download an artifact, and suggesting a tool for accessing it. The submitter must:
- Download the
.zip artifact, for which a link is provided.
- Extract the
.sarif file.
- Upload that file to a website, or otherwise deploy a tool of some kind to access it.
- Drill down multiple times to find the results that are relevant to the discovered issue. Not all tools make it clear in an accessible way, that results can even be sufficiently drilled into to find actual line number and error information.
I suggest that this is unnecessarily cumbersome, and unfriendly to users who don't normally work with SARIF files. I think we can do better.
Ideas, in descending order of preference.
- Extract relevant portions of the SARIF file, and post them directly in an issue comment. I haven't found a GitHub action for this yet, but there may be tools we can use to build our own. At the very least, more basic tools could do it. It is likely that a submitter needs mainly the filename, line number, line contents, and error text for each problem discovered, along with the classification of the error. Similar to what a linter would provide.
- Use something like NeuroWall SARIF Viewer to create an HTML report, upload that directly as an artifact, and publish a link to it in the comment. Better than making the user obtain a development tool or find an accessible web-based viewer, though not the best idea. It may be a start. We could even do a text extract on an exploded version of the report, and post that directly in the comment; although I think option (1) becomes better at that point.
- At the very least, we could upload the
.sarif file directly as the artifact, instead of using the zip/unzip step. I believe the artifact upload action compresses non-zip files for transfer anyway, so we aren't saving bandwidth on the workflow side by zipping these. The convenience to the user of directly downloading the file should be more valuable.
When a security issue is discovered in an add-on submission, a report in
.sarifformat is produced. Then, a comment is posted instructing thesubmitter to download an artifact, and suggesting a tool for accessing it. The submitter must:
.zipartifact, for which a link is provided..sariffile.I suggest that this is unnecessarily cumbersome, and unfriendly to users who don't normally work with SARIF files. I think we can do better.
Ideas, in descending order of preference.
.sariffile directly as the artifact, instead of using the zip/unzip step. I believe the artifact upload action compresses non-zip files for transfer anyway, so we aren't saving bandwidth on the workflow side by zipping these. The convenience to the user of directly downloading the file should be more valuable.