doc: add extra step reporter pre-approval

[RafaelGSS]

As discussed in the #security-triagge (OpenJS channel). To avoid insufficient CVE fixes across Security Release, might make sense to request a reporter pre-approval.

cc: @nodejs/tsc

[nodejs-github-bot]

Review requested:

• @nodejs/tsc

[mhdawson]

@RafaelGSS While that would be great, I think that might be a bit of an ask on the steward. It might require building on platforms that are not available to them and also quite a lot of work if there are many vulnerabilities.

I think instead sharing the patch in the H1 issue with the reporter would be more manageable.

[RafaelGSS]

I think instead sharing the patch in the H1 issue with the reporter would be more manageable.

The problem is that sometimes the patch might not be so obvious and considering the fact of the Node.js codebase is complex, I doubt the reporter could validate the fix easily.

I've included that option as optional, because as you said, sometimes might not be feasible to share a binary with the reporter due to its architecture.

[mcollina]

I'm not comfortable with this change given our current process. The problem is that we won't have the binary available until its release time and we have locked CI.

[RafaelGSS]

I'm not comfortable with this change given our current process. The problem is that we won't have the binary available until its release time and we have locked CI.

The suggestion is for the releaser to build the binary locally and send it to the reporter. As mentioned before, sometimes it might not be possible due to different architectures between the releaser and reporter (that's the reason this option is optional). But, I see this as a good step to avoid further insufficient security fixes.

[tniessen]

Assuming this is motivated by a particular issue which I won't mention because this is a public discussion, I want to remark that the patches that were developed did address the respective report (for the most part). It was either much later or a different person that found a way to circumvent the fix in a way that was not described in previous reports. In these cases, the respective reporter might have agreed that a patch was sufficient because they themselves weren't aware of other special cases at that time.

We have also had reporters submit patches themselves that turned out to be insufficient or wrong.

That being said, when I found a vuln in OpenSSL, the maintainers did share all the patches with me and asked for feedback, which was a good experience for both sides, I think. In that particular case, it worked out nicely, but even then, I didn't have much to say about the patch because I am not that familiar with their code base. I could easily have missed a bug in the patch.

[RafaelGSS]

Great feedback @tniessen, thanks!

To summarize, we have two proposals on the table (we can choose both, btw):

1. Build the binary locally and send to the reporter
   • Pros:
     • the reporter may run a few tests to guarantee the vulnerability was fixed.
   • Cons:
     • the releaser and the reporter must be system compatible
     • other vulnerabilities can be created while fixing the reported one
2. Share the patches before the release with the reports
   • Pros:
     • we might avoid creating new vulnerabilities through reporter code-review
   • Cons:
     • rarely, the reporter will have enough knowledge to understand/review changes in the Node.js codebase
     • currently, we don't have a good way to share the patches that affect more than 1 single file. We can obviously paste the whole diff in the report, but that won't make the review any easier.

[RafaelGSS]

So, we've discussed this PR at the Collab Summit (nodejs/Release#785) and we've agreed to use both approaches. I've adjusted the content to also include the diff share. We are also evaluating the efforts to use our build system to build each patch and provide it to the reporter itself. But that's another topic.

cc: @nodejs/releasers

[mcollina]

lgtm

[nodejs-github-bot]

Landed in deb9f5e