Kyle Stanley <aeros...@gmail.com> added the comment: > I think you can use SO_REUSEPORT instead, and for UDP sockets it's identical > to SO_REUSEADDR except with the same-UID restriction added?
> If that's right then it might make sense to unconditionally switch > SO_REUSEADDR -> SO_REUSEPORT, even in existing Python releases – on the > theory that it fixes the main security hole, while being back-compatible > enough to be acceptable for a point release. +1, I think this is the best proposal so far. From my reading of http://man7.org/linux/man-pages/man7/socket.7.html (specifically the SO_REUSEPORT section) this seems correct. Emitting a `DeprecationWarning` and a delayed change for the default value of `reuse_address` not only leaves open a security concern for the near future (until the change is actually made); it also has a maintenance cost for users and libraries. Also, changing the default value wouldn't address the problem for those who explicitly specified `reuse_address=True`. The way I see it, changing `socket.SO_REUSEADDR` to `socket.SO_REUSEPORT` would apply the security fix more rapidly, fix the issue for more users, and have a much lower (if not zero) maintenance cost for the majority of users. This would also allow us to apply the change to more previous Python versions, since it doesn't affect asyncio's public API. If we're just changing `socket.SO_REUSEADDR` to `socket.SO_REUSEPORT` at: https://github.com/python/cpython/blob/7eee5beaf87be898a679278c480e8dd0df76d351/Lib/asyncio/base_events.py#L1321 We should be able to apply to change starting from Python 3.5+, no? I should have the time to open a PR with backports within the next day if needed, particularly since it's a fairly small code change. I'll leave that up to Nathaniel though since he came up with the idea, let me know either way. ---------- nosy: +aeros _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue37228> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
