Update security policy to include guidance on "Supported Versions"

[sethmlarson]

What's the problem this feature will solve?

Usually security policies will include guidance on what versions are eligible for security fixes. I believe pip's historical behavior has been to only apply security patches to the latest release of pip (not backporting security fixes). If this isn't correct we can amend this to whatever future behavior the pip maintainers would like to do for security fixes.

Describe the solution you'd like

Update security policy with guidance on supported versions.

Alternative Solutions

N/A

Additional context

#12254

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[pfmoore]

Historical behaviour has been to treat security issues just like any other issue - someone (which may be a community member) needs to create a PR, which will be merged and then released as part of the next scheduled release of pip. My feeling is that people would read "the latest version is eligible for security fixes" as implying more than that - see #12259 as evidence of this.

I think we need to be very careful not to commit in our security policy to something that we don't have the resources to deliver.

[sethmlarson]

Historical behaviour has been to treat security issues just like any other issue - someone (which may be a community member) needs to create a PR, which will be merged and then released as part of the next scheduled release of pip. My feeling is that people would read "the latest version is eligible for security fixes" as implying more than that - see #12259 as evidence of this.

Let me know if I'm reading your reply correctly: your concern is primarily about the wording implying more work than what is done today wrt releases being made outside the schedule.

My phrasing was attempting to capture that if a security issue got reported for an old version of pip but the latest version wasn't affected then the pip team wouldn't be creating a patch for that vulnerability (our guidance would be to upgrade to latest). Also if a vulnerability got fixed in the latest version of pip but the vuln affected all versions of pip we wouldn't be providing patches that cleanly apply to older versions (that would be the user/downstream distributor responsibility to adapt the upstream patch).

I think we need to be very careful not to commit in our security policy to something that we don't have the resources to deliver.

Agreed! Part of my work is highlighting where more resources need to go or where improvements can be made. Solutions that take the form of (With X, we could achieve Y) are perfect candidates (where X could be "work in this area, more people, money, etc" and Y could be "out-of-band security releases").

[pfmoore]

Let me know if I'm reading your reply correctly: your concern is primarily about the wording implying more work than what is done today wrt releases being made outside the schedule.

Precisely.

The current reality is that we don't normally do any sort of bugfix releases outside of critical issues introduced by a release. Our bugfix window for a release is typically only a week or two after the release for emergency fixes to major breakages in the release. Everything else (bugfix or feature) waits for the next scheduled release. And while it (luckily) doesn't happen often, this applies just as much to security bugs as any other form.

I would be fine with a security policy which made this clear. As a case in point, I'd be happy if we could respond to #12259 by simply saying "as per our security policy, the fix will be in our next scheduled release in October" and leave it at that.

We'd also need to incorporate some form of wording that made it clear that if no-one provides a fix for a security issue, we won't be able to release one. This is effectively an explicit acknowledgement that we rely heavily on community contributions for bugfixes. And somehow we'd also need to capture the fact that if none of the pip maintainers are able to review a security fix (whether due to lack of time, lack of expertise, or a particularly complex PR) there's even the possibility that we could have a security issue, and a PR claiming to fix it, and we'd still not be able to get the fix into the next scheduled release.

Part of my work is highlighting where more resources need to go or where improvements can be made. Solutions that take the form of (With X, we could achieve Y) are perfect candidates (where X could be "work in this area, more people, money, etc" and Y could be "out-of-band security releases").

None of this is new, and it's a common problem across many Python packaging projects. It's just basic lack of people with a sufficient level of trust and commitment to become maintainers - PyPI is critically short of resources as well, as is setuptools (I believe).

https://xkcd.com/2347/ feels very relevant¹ here...

Footnotes

1. Except that to my knowledge, none of the pip maintainers live in Nebraska 🙂 ↩