Repository navigation
Fallback socketpair authentication is unreliable on WASI #146139
Description
Bug report
Bug description:
#122133 introduced authentication for the fallback socketpair implementation in Lib/socket.py. However, that's unreliable on WASI (and possibly elsewhere), where calling connect(2) on a non-blocking socket may leave the socket in a "connecting" but not yet "connected" state. In the former case, calling getpeername(2) on it will fail, leading to an unhandled exception in Python.
More generally, I'm a bit surprised the authentication code works reliably on any platform; I don't believe POSIX guarantees getpeername(2) will succeed for a socket which may or may not have finished connecting. Perhaps other platforms reliably complete loopback connections synchronously for non-blocking sockets?
Note that WASI socket support is not yet enabled by default in CPython, but is available via componentize-py, which has been carrying a patch to CPython which I'm finally getting around to submitting upstream.
Given the unofficial state of WASI sockets in CPython, reproducing the issue is a bit awkward, but can be done by:
- cloning the
componentize-pyGit repo (e.g.git clone --recurse-submodules https://github.com/bytecodealliance/componentize-py), - switching to the
cpythonsubdirectory, removing the aforementioned patch (e.g.git reset --hard HEAD^), - following the directions in
CONTRIBUTING.mdto build everything, - installing Wasmtime,
- and finally running
cargo test --release --test componentize tcp_example
...at which point you'll see something like:
Traceback (most recent call last):
File "/0/app.py", line 17, in run
File "/python/asyncio/runners.py", line 203, in run
File "/python/asyncio/runners.py", line 59, in __enter__
File "/python/asyncio/runners.py", line 146, in _lazy_init
File "/python/asyncio/events.py", line 844, in new_event_loop
File "/python/asyncio/events.py", line 732, in new_event_loop
File "/python/asyncio/unix_events.py", line 61, in __init__
File "/python/asyncio/selector_events.py", line 66, in __init__
File "/python/asyncio/selector_events.py", line 120, in _make_self_pipe
File "/python/socket.py", line 645, in _fallback_socketpair
OSError: [Errno 53] Socket not connected
I plan to post a PR for this shortly.
CPython versions tested on:
3.14
Operating systems tested on:
Other
Activity
dicej commentedon Mar 18, 2026
cc @brettcannon @sethmlarson In case you have thoughts or opinions.
pythongh-146139: Disable `socketpair` authentication on WASI
vstinner commentedon Mar 19, 2026
socketpair() is only implemented in pure Python in
Lib/socket.pyif_socket.socketpair()doesn't exist. On most platforms (ex: Linux),_socket.socketpair()exists and so the pure Python implementation is not used.dicej commentedon Mar 19, 2026
Right, I understand that. What I'm wondering is which platform(s) #122133 and #122134 were intended to address, since they were clearly targeted at (and only affect) platforms which use the pure Python version.
vstinner commentedon Mar 19, 2026
I'm only aware of Windows which lacks
_socket.socketpair(). I didn't know that WASI also lacks_socket.socketpair().brettcannon commentedon Mar 19, 2026
I have no opinion as I'm not a networking expert and I've been waiting to avoid worrying about it until WASI 0.3 + threads shows up. 🫣
pythongh-146139: Disable `socketpair` authentication on WASI
gh-146139: Disable `socketpair` authentication on WASI (#146140)
pythongh-146139: Disable `socketpair` authentication on WASI (pythonG…
pythongh-146139: Disable `socketpair` authentication on WASI (pythonG…
[3.13] gh-146139: Disable `socketpair` authentication on WASI (GH-146140
[3.14] gh-146139: Disable `socketpair` authentication on WASI (GH-146140
pythongh-146139: Disable `socketpair` authentication on WASI (python#…