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-py Git repo (e.g. git clone --recurse-submodules https://github.com/bytecodealliance/componentize-py),
- switching to the cpython subdirectory, removing the aforementioned patch (e.g. git reset --hard HEAD^),
- following the directions in CONTRIBUTING.md to 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 commented on Mar 18, 2026
cc @brettcannon @sethmlarson In case you have thoughts or opinions.
pythongh-146139: Disable `socketpair` authentication on WASI
vstinner commented on Mar 19, 2026
socketpair() is only implemented in pure Python in Lib/socket.py if _socket.socketpair() doesn't exist. On most platforms (ex: Linux), _socket.socketpair() exists and so the pure Python implementation is not used.
dicej commented on 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 commented on Mar 19, 2026
I'm only aware of Windows which lacks _socket.socketpair(). I didn't know that WASI also lacks _socket.socketpair().
brettcannon commented on 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#…