Following up to myself...
Mark Geisert wrote:
Hi Fabian,
Fabian Henze wrote:
Hi all,
This is a follow-up on a mail thread from February 2021.
Mark Geisert via Cygwin wrote:
Fabian Henze via Cygwin wrote:
Hi Cygwin users,
I noticed a regression in the recent Python packages: Between version
3.6.10-1 and 3.6.12-2, accessing the SSH agent via the paramiko python
package broke. When a ssh agent is used, paramiko tries to connect to
it via the unix socket and just freezes. Python 3.8 is also affected,
but I don't know which was the last working one.
I was able to pinpoint that error to 3.6.12-socketmodule.patch [1].
Reverting/removing the patch fixes the ssh agent access.
[...]
Can you please check if you are able to reproduce that? I uploaded a
script [3] for that.
Best regards,
Fabian Henze
Thanks for the report and sorry you've run into this. The patch is a
workaround that's evidently too draconian. I will debug the situation using
your testcase.
Thank you very much for the testcase.
Did you (or anyone else) make any progress on this that you can share?
Unfortunately the issue still persists in all current python versions.
If no one has time to debug and fix this, would it be an option to remove the
3.6.12-socketmodule.patch that is causing the regression since it only fixes a
theoretical problem in unit tests, but causes real-world issues? Maybe the
upcoming (?) Python 3.10 or 3.11 bump would be a good candidate to do so?
[...]
Let me find my notes for this issue and see if I can improve on the patch or find
some other solution for now-current versions of Python and/or Cygwin DLL.
Right. I determined there was nothing further I could do. The conclusion I stated
in the thread you quoted from was this (and it still applies):
--------8<--------
It's a limitation of the patch. It was meant to allow Python programs on the
same
computer to communicate via AF_UNIX sockets, by working around less than perfect
support in the Cygwin DLL. But you've got a Python program trying to
communicate
with a non-Python program, and that fails because the patch is only applied on
the
Python end of the connection.
If you can continue to run without the problematic patch, that's your best
option.
-------->8--------
BTW, what you called "a theoretical problem in unit tests" was of great concern to
the Cygwin Python maintainer at the time. We test our Python builds before
releasing them.
The best "solution" I can think of ATM, and it's not great, is to have the
behavior you want be the default and an environment variable such as
PYTHON_NET_DISABLE_CREDENTIALS to choose the other behavior. I will consult the
Cygwin Python maintainer to see if this is acceptable.
..mark
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
