-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Update security policy #12254
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
Update security policy #12254
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.
I initially thought this PR was simply a documentation fix, but it's actually a change in policy, and we need to ensure we can deliver on whatever we commit to in the docs.
SECURITY.md
Outdated
|
||
## Supported Versions | ||
|
||
The pip team applies security fixes to the latest version of pip [available on PyPI](https://pypi.org/project/pip/) |
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.
Um, this isn't technically true. We certainly don't backport security fixes, but we typically don't apply them to the latest version either - they simply get applied to main and then released with the next scheduled release.
I imagine that we would create a bugfix release for a sufficiently serious vulnerability, but it's not policy that we must - and it implies an additional commitment for the RM of a given release if we change our policy to do this (we'd need to cherry-pick the fix onto the release branch, which could be non-trivial to do if there have been other changes to the affected code in main).
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.
Actually, there's a further implied point here - it says we "apply security fixes", but this makes no comment on the fact that unless someone contributes a fix, we will not necessarily do anything. And even if someone does, we may not have the expertise to review the fix. So I'm concerned that the text as written sets an expectation that we may not be able to deliver on.
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.
Thanks for the review, I've created a separate issue since it seems like this will need more discussion. The primary focus of this issue is in the "Reporting a vulnerability" section and to ensure that reporters are following the correct process.
Does this PR need a news entry? I thought it didn't, but now I feel like a |
Probably the "process" type would be best. |
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, assuming a reasonable changelog entry is added.
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.
As noted this needs a changelog entry, but otherwise LGTM
@pradyunsg @pfmoore Done! Thanks for the reviews. |
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.
Now it's ready (at least from my side), thanks @sethmlarson!
Updates the security policy to provide guidance about supported versions and link to the CNA/PSRT disclosure process. Please check that the "Supported Versions" section matches the actual supported versions by the pip team. cc @pradyunsg