-
-
Notifications
You must be signed in to change notification settings - Fork 31.2k
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
bpo-37228: Fix loop.create_datagram_endpoint()'s usage of SO_REUSEADDR #17311
bpo-37228: Fix loop.create_datagram_endpoint()'s usage of SO_REUSEADDR #17311
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 actually think that Antoine solution is more preferable. @asvetlov?
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
I prefer Antoine's solution as well as far as elegance and API design goes, my only concern is that it would be fairly disruptive with regards to backwards compatibility (from raising an error upon passing Edit: If the consensus is to use Antoine's proposal instead, I can modify this PR accordingly. As long as it's within the next couple of days, I should have the time to do so. If I don't have enough time, I'll close this PR and let someone else implement it. |
aae05e6
to
e3c895c
Compare
e3c895c
to
397c9be
Compare
Due to Windows compatibility concerns, I no longer think that changing |
397c9be
to
d748ca1
Compare
Doc/library/asyncio-eventloop.rst
Outdated
@@ -527,6 +529,10 @@ Opening network connections | |||
The *family*, *proto*, *flags*, *reuse_address*, *reuse_port, | |||
*allow_broadcast*, and *sock* parameters were added. | |||
|
|||
.. versionchanged:: 3.5.10 |
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'm assuming that version 3.5.10 would be the next released 3.5.x, and the earliest version that this change will apply to. Is this correct?
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.
Since this is being added to multiple releases mid-stream, I think the right approach is for each branch to have its own versionchanged value, except perhaps master which would also have the 3.8 version (since 3.9 isn't released yet). So perhaps change this to the right 3.8.x version and then either manually cherry-pick for 3.7 and earlier (which might need to be done anyway if there are merge conflicts) or submit separate post-merge PRs for them to change the versionadded value.
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.
So perhaps change this to the right 3.8.x version and then either manually cherry-pick for 3.7 and earlier (which might need to be done anyway if there are merge conflicts) or submit separate post-merge PRs for them to change the versionadded value.
Sounds good, I can do that. I'll set master and the 3.8 branch to 3.8.1; 3.7 to 3.7.6; 3.6 to 3.6.10; and 3.5 to 3.5.10. The easiest way to handle this would probably be through using cherry-pick to open the backport PRs manually. As a result, I'll remove the ``needs backport to x` labels, so that @miss-islington doesn't automatically open the backport PRs.
Should we check with @larryhastings regarding the 3.5 backport? I believe it would be appropriate since this is a significant security vulnerability.
Thanks for making the requested changes! @1st1: please review the changes made to this pull request. |
I'll add a Misc/NEWS entry. |
Based on @ned-deily's suggestion to manually set the If this PR is accepted and merged, I'll use Regarding the "What's New" entries, I would prefer to do those separately to simplify the merge conflicts. I'll have definitely time to take care of this on Monday, but for today and tomorrow I'll likely be busy with finishing up my final exams (last week of the Fall semester). I should have time to make very small changes or reply to feedback, but I will likely not have time to do anything substantial until Monday (Dec 9th), unless I'm able to finish my work early on Sunday. Edit: If any larger changes are needed before Monday, feel free to open a PR to my branch at https://github.com/aeros/cpython/tree/bpo37228-create_datagram_endpoint-reuse_address and I should be able to merge it. I've also ticked |
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
@ambv: Please replace |
pythonGH-17311) (cherry picked from commit ab513a3) Co-authored-by: Kyle Stanley <[email protected]>
GH-17529 is a backport of this pull request to the 3.8 branch. |
GH-17311) (#17529) (cherry picked from commit ab513a3) Co-authored-by: Kyle Stanley <[email protected]>
Note: merged for 3.8 and 3.9. @aeros removed backport labels to 3.6 and 3.7 here. The issue on BPO still lists those versions as affected. Please fix either way. |
This is because they need to be manually backported, due to a difference in the |
pythonGH-17311) (pythonGH-17529) (cherry picked from commit ab513a3) Co-authored-by: Kyle Stanley <[email protected]>
GH-17311) (GH-17570) (cherry picked from commit ab513a3) Co-authored-by: Kyle Stanley <[email protected]>
python#17311) (cherry picked from commit ab513a3)
…USEADDR (pythonGH-17311). (cherry picked from commit ab513a3) Co-authored-by: Kyle Stanley <[email protected]>
…USEADDR (GH-17311). (GH-17571) (cherry picked from commit ab513a3) Co-authored-by: Kyle Stanley <[email protected]>
Edit: This PR has been revised based on @pitrou's proposal, due to Windows compatibility concerns.
https://bugs.python.org/issue37228