gh-146139: Disable socketpair authentication on WASI#146140
gh-146139: Disable socketpair authentication on WASI#146140vstinner merged 3 commits intopython:mainfrom
socketpair authentication on WASI#146140Conversation
|
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
|
@dicej: You should sign the Python CLA: #146140 (comment). |
|
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
|
Regarding the CLA: I've asked my employer for permission to sign it and am awaiting a reply. |
Any update on the CLA @dicej? |
Yes: I need my employer to sign it as an organization to cover my contributions (i.e. I'm not supposed to sign as an individual contributor), which means using this form, but it's not clear how we should fill that out given that the signatory (i.e. the person with authority to sign for the whole organization) and the contributor(s) (e.g. me) will be different people. I sent an email to psf@python.org for clarification and was redirected to contributors@python.org, but haven't heard back yet. Given this is effectively a one-line change modulo whitespace, it all feels like overkill, but this should unblock future contributions as well. |
It's fine if they are different people. The key thing is if someone from Akamai is submitting for the entire org then they just need to be empowered to sign such a form to say any contributions coming from someone on work time is covered by the CLA. |
|
I still haven't received a response from contributors@python.org. Can anyone confirm that, if an authorized party at Akamai signs the CLA form on behalf of Akamai, any contributions from a |
|
@ambv: Do you know how to proceed for the CLA in this case? |
|
The company has to sign on the Python.org website, checking the box for signing as an organization.
and the individual has to sign via GitHub sign-in through https://cla.python.org/ which cover that individuals contributions |
Calling `connect(2)` on a non-blocking socket on WASI 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.
Co-authored-by: Victor Stinner <vstinner@python.org>
eb851ef to
e71d5a7
Compare
|
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
|
Thanks, @JacobCoffee. The CLA is signed now. |
|
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
|
@dicej can you look at the failures (e.g. missing a news entry)? |
|
"_RegenSbom" failed with "HTTP error 503: Service Unavailable" on Windows. I re-ran the failed (Windows) jobs. |
|
Let's skip the NEWS entry. |
…H-146140) Calling `connect(2)` on a non-blocking socket on WASI 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. (cherry picked from commit a5b76d53bb29afd864243f44ef22968f6385dfa0) Co-authored-by: Joel Dice <joel.dice@akamai.com> Co-authored-by: Victor Stinner <vstinner@python.org> Co-authored-by: Brett Cannon <brett@python.org>
|
GH-148526 is a backport of this pull request to the 3.14 branch. |
…H-146140) Calling `connect(2)` on a non-blocking socket on WASI 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. (cherry picked from commit a5b76d5) Co-authored-by: Joel Dice <joel.dice@akamai.com> Co-authored-by: Victor Stinner <vstinner@python.org> Co-authored-by: Brett Cannon <brett@python.org>
|
GH-148527 is a backport of this pull request to the 3.13 branch. |
|
Thanks @dicej for the fix and signing the CLA. I backported the fix to 3.13 and 3.14 branches. |
) (#148527) gh-146139: Disable `socketpair` authentication on WASI (GH-146140) Calling `connect(2)` on a non-blocking socket on WASI 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. (cherry picked from commit a5b76d5) Co-authored-by: Joel Dice <joel.dice@akamai.com> Co-authored-by: Victor Stinner <vstinner@python.org> Co-authored-by: Brett Cannon <brett@python.org>
) (#148526) gh-146139: Disable `socketpair` authentication on WASI (GH-146140) Calling `connect(2)` on a non-blocking socket on WASI 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. (cherry picked from commit a5b76d5) Co-authored-by: Joel Dice <joel.dice@akamai.com> Co-authored-by: Victor Stinner <vstinner@python.org> Co-authored-by: Brett Cannon <brett@python.org>
Calling
connect(2)on a non-blocking socket on WASI may leave the socket in a "connecting" but not yet "connected" state. In the former case, callinggetpeername(2)on it will fail, leading to an unhandled exception in Python.socketpairauthentication is unreliable on WASI #146139