Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
we cannot increase the upper bound, as some of our downstream packages didn't migrate yet to requests 2.29.0+, lower bound can be decreased if it passes the tests.
see 1ea8f3b and psf/requests#6432
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.
Surely, the downstream packages should be responsible for pinning requests?! This is a publicly available package which can't be used with a version of requests without public security vulnerabilities (https://github.com/psf/requests/blob/main/HISTORY.md#2310-2023-05-22)...
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.
we'll update the upper bound once our downstream packages update their upper bound
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.
@nfx am I correct in understanding that the issue with supporting requests 2.29+ is to do with a mismatch in available ssl modules and
urllib3
version 2.x (i.e: similar to urllib3/urllib3#2168)? If so, perhaps this package could pin tourllib3<2
(as the release notes forrequests
2.30 suggest) as that would appear to avoid the issue? That would allow forrequests
to move forward to a version which has the security fix (i.e: 2.31) while keeping to the known-working version ofurllib3
.I agree with @judahrand that such pinning really ought to be the responsibility of the downstream libraries/applications which actually depend on the particular versions of
requests
/urllib3
, however if it's important to you that this package not admiturllib3
related issues then perhaps my suggestion above presents a way forwards.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.
@PeterJCLaw @judahrand Sorry for the delay in addressing this ticket. As we saw during the original bump of urllib3, major version increases with backwards incompatibility has major risks for dependent software. We wanted to verify that at least our internal products wouldn't have yet another regression if we were to unpin this too soon. Especially with the release of 2.0.3, users who do not pin urllib3 in their setup.py or requirements.txt are likely to get a version that is compatible with their system's version of SSL. So, we're ready to merge this patch. This will be released in the next minor version (0.2.0).