-
-
Notifications
You must be signed in to change notification settings - Fork 806
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
Add PSRT coordination process and messaging templates #1348
Conversation
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.
Interesting approach to line wrapping 😆 But otherwise it looks great.
Looking forward to seeing how the GitHub Advisories stuff works. I've never been on this side of it before.
|
||
Please see the linked CVE ID for the latest information on affected versions: | ||
|
||
* https://www.cve.org/CVERecord?id={CVE-YYYY-XXXX} |
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.
This link won't work on initial disclosure, right? Or do they activate that quickly?
Agreed with keeping it in the initial email though, since these get publicly archived and essentially are our disclosure mechanism.
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 becomes public almost instantly after it's pushed, but yes it requires a manual publication from the PSF CNA.
developer-workflow/psrt.rst
Outdated
|
||
* Affected versions. This could be "all versions", but if the vulnerability exists in a new feature | ||
or removed feature then this could be different. Include versions that are end-of-life in this calculation. | ||
(e.g. "Python 3.9 and earlier", "Python 3.10 and later", "all versions of Python") |
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.
Should we be more precise with these? Generally it's going to be "all the latest versions as of the day we disclose", which means we can easily figure out the real list.
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 might also be useful to describe which versions are (or will be) EOL as of the disclosure date.
Very minor formatting and spelling fixes. `code-block` is I think incorrect in that the examples are plain text, so just use `::` to delineate.
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.
Sorry, I couldn't figure out how to suggest a change so I just went ahead and committed a few minor typo and formatting changes. Other than that, and the comments by the others, LGTM!
Co-authored-by: Ezio Melotti <[email protected]> Co-authored-by: Steve Dower <[email protected]>
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.
Some additional nitpicking: wavy subsections are frowned upon.
* Remove more contractions. * Fix the header format ('~' -> '-') * Indicate more clearly which steps of the process are done by the coordinator. * Limit the line lengths of template responses to 80 chars
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 rendered Rejecting a vulnerability report template is still incorrectly formatted. I believe a .. highlight:: none
will fix 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.
LGTM
Co-authored-by: Hugo van Kemenade <[email protected]> Co-authored-by: Ezio Melotti <[email protected]>
Thanks @hugovk and @ezio-melotti for putting together the review comments with fixes! 🙏 |
I don't have any further thoughts or suggestions at this point, but I'm assuming we'll refine things as we go. (If the intent is to lock us into this process precisely, then I'll take the time to be more thorough and imaginative before approving.) |
@zooba We can continue to refine the process as we learn more and encounter edge-cases, this gives us a better place for those improvements to land instead of becoming "institutional knowledge" :) |
I think all reviewers have left their comments or approved including all PSRT admins. Thanks everyone for the reviews! Happy whenever we're ready to merge this one. |
Thanks @hugovk! 🙏 |
This documents the process for PSRT coordination which matches the proposal sent to the Python Security Response Team. Note that GitHub Security Advisories are not yet active for the CPython repository, but this process works mostly the same just without a canonical place to record the information and collaborate.
cc @zooba @gpshead @ned-deily @warsaw
📚 Documentation preview 📚: https://cpython-devguide--1348.org.readthedocs.build/