-
Notifications
You must be signed in to change notification settings - Fork 29.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doc: revise security-reporting example text #23759
Conversation
Edit for simplicity and clarity.
@nodejs/security-wg @nodejs/security-triage |
Buffer(num) by default_. The documented `Buffer()` behavior was prone to | ||
[misuse](https://snyk.io/blog/exploiting-buffer/). It has since changed. It | ||
was not deemed serious enough to fix in older releases and breaking API | ||
stability. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe "breaking API stability" -> "changing the API in a backwards incompatible way"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this even really true? (I'm talking about both the existing text and your revision.) The issue was zero-filling vs. not zero-filling, but whether that broke API compatibility was (and is) up for debate. IMO, there was never any guarantee about the contents of a buffer created that way, so this did not break API compatibility. Even the one person saying it broke API compatibility in nodejs/CTC#91 hedged. (@rvagg described it as "technically breaking".)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's even more confusing because it's a pull request and not an issue. I wonder if we shouldn't just remove this from the list altogether TBH.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The fact that it was ultimately deemed not worth backporting was an issue that had divided opinion on the CTC. To expect a reporter to make that sort of judgment call is unfair, I think. Moreover, I'm not sure what that even has to do with whether or not to disclose privately. Maybe the real point here is that the vulnerability was already well-known by the time the pull request was opened. But that's not going to help someone who is wondering whether they should disclose something to us privately or publicly. (IMO, the answer should be: If you're even asking that question, disclose privately.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don’t think Buffer constructor is a good example for this. Maybe can we just remove it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will land as-is and revise this part subsequently, since I'm looking the immediately-following section next...
Edit for simplicity and clarity. PR-URL: nodejs#23759 Reviewed-By: Sam Roberts <[email protected]> Reviewed-By: Matheus Marchini <[email protected]> Reviewed-By: Vladimir de Turckheim <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]>
Landed in 2fc0752 |
Remove Buffer constructor example from security reporting examples. Even though the example text focuses on API compatibility, the pull request cited is about zero-filling vs. not zero-filling, which is not an API compatibility change (or at least is not unambiguously one). The fact that it's a pull request is also problematic, since it's not reporting a security issue but instead proposing a way to address one that has already been reported publicly. Finally, the text focuses on the fact that it was not deemed worth of backporting, but that was determined by a vote by a divided CTC. It is unreasonable to ask someone reporting an issue to make a determination that the CTC/TSC is divided on. In short, it's not a good example for the list it is in. Remove it. Refs: nodejs#23759 (comment)
Edit for simplicity and clarity. PR-URL: #23759 Reviewed-By: Sam Roberts <[email protected]> Reviewed-By: Matheus Marchini <[email protected]> Reviewed-By: Vladimir de Turckheim <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]>
Remove Buffer constructor example from security reporting examples. Even though the example text focuses on API compatibility, the pull request cited is about zero-filling vs. not zero-filling, which is not an API compatibility change (or at least is not unambiguously one). The fact that it's a pull request is also problematic, since it's not reporting a security issue but instead proposing a way to address one that has already been reported publicly. Finally, the text focuses on the fact that it was not deemed worth of backporting, but that was determined by a vote by a divided CTC. It is unreasonable to ask someone reporting an issue to make a determination that the CTC/TSC is divided on. In short, it's not a good example for the list it is in. Remove it. Refs: nodejs#23759 (comment) PR-URL: nodejs#23817 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Trivikram Kamat <[email protected]>
Remove Buffer constructor example from security reporting examples. Even though the example text focuses on API compatibility, the pull request cited is about zero-filling vs. not zero-filling, which is not an API compatibility change (or at least is not unambiguously one). The fact that it's a pull request is also problematic, since it's not reporting a security issue but instead proposing a way to address one that has already been reported publicly. Finally, the text focuses on the fact that it was not deemed worth of backporting, but that was determined by a vote by a divided CTC. It is unreasonable to ask someone reporting an issue to make a determination that the CTC/TSC is divided on. In short, it's not a good example for the list it is in. Remove it. Refs: #23759 (comment) PR-URL: #23817 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Trivikram Kamat <[email protected]>
Edit for simplicity and clarity. PR-URL: #23759 Reviewed-By: Sam Roberts <[email protected]> Reviewed-By: Matheus Marchini <[email protected]> Reviewed-By: Vladimir de Turckheim <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]>
Remove Buffer constructor example from security reporting examples. Even though the example text focuses on API compatibility, the pull request cited is about zero-filling vs. not zero-filling, which is not an API compatibility change (or at least is not unambiguously one). The fact that it's a pull request is also problematic, since it's not reporting a security issue but instead proposing a way to address one that has already been reported publicly. Finally, the text focuses on the fact that it was not deemed worth of backporting, but that was determined by a vote by a divided CTC. It is unreasonable to ask someone reporting an issue to make a determination that the CTC/TSC is divided on. In short, it's not a good example for the list it is in. Remove it. Refs: #23759 (comment) PR-URL: #23817 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Trivikram Kamat <[email protected]>
Edit for simplicity and clarity. PR-URL: #23759 Reviewed-By: Sam Roberts <[email protected]> Reviewed-By: Matheus Marchini <[email protected]> Reviewed-By: Vladimir de Turckheim <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]>
Remove Buffer constructor example from security reporting examples. Even though the example text focuses on API compatibility, the pull request cited is about zero-filling vs. not zero-filling, which is not an API compatibility change (or at least is not unambiguously one). The fact that it's a pull request is also problematic, since it's not reporting a security issue but instead proposing a way to address one that has already been reported publicly. Finally, the text focuses on the fact that it was not deemed worth of backporting, but that was determined by a vote by a divided CTC. It is unreasonable to ask someone reporting an issue to make a determination that the CTC/TSC is divided on. In short, it's not a good example for the list it is in. Remove it. Refs: #23759 (comment) PR-URL: #23817 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Trivikram Kamat <[email protected]>
Edit for simplicity and clarity. PR-URL: #23759 Reviewed-By: Sam Roberts <[email protected]> Reviewed-By: Matheus Marchini <[email protected]> Reviewed-By: Vladimir de Turckheim <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]>
Remove Buffer constructor example from security reporting examples. Even though the example text focuses on API compatibility, the pull request cited is about zero-filling vs. not zero-filling, which is not an API compatibility change (or at least is not unambiguously one). The fact that it's a pull request is also problematic, since it's not reporting a security issue but instead proposing a way to address one that has already been reported publicly. Finally, the text focuses on the fact that it was not deemed worth of backporting, but that was determined by a vote by a divided CTC. It is unreasonable to ask someone reporting an issue to make a determination that the CTC/TSC is divided on. In short, it's not a good example for the list it is in. Remove it. Refs: #23759 (comment) PR-URL: #23817 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Trivikram Kamat <[email protected]>
Edit for simplicity and clarity.
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes