Re: [Python-Dev] Other SSL issues in the tracker have been marked
On 8/26/07, Bill Janssen <janssen@parc.com> wrote:
For ia64 http://python.org/dev/buildbot/all/ia64%20Ubuntu%20trunk%20trunk/builds/833/... pybot@noisy:~$ openssl version OpenSSL 0.9.8b 04 May 2006 I have access to some of the machines but not all of them. All of these run inside a chroot which might be causing a problem. I remember some issues with getting socket stuff to work right on them. But that was over a year ago and I don't remember the details now. :-( svn/google probably knows if you want to trawl through checkins. I'm not sure that will help much though. On this machines I was able to successfully make a key. That's why I'm thinking it might be some strange socket issue.
Yeah, I know this is difficult. Hopefully someone with WIndows will step up to help. We can at least make the test more robust and verify the files exist and are non-zero in size. I will do that now. At least the it shouldn't cause the test to time out. n
Yes, the patch I sent out should fix that. I'd like to know, for the machines where the test is failing, what's in the generated cert file -- should be an RSA PRIVATE KEY and a CERTIFICATE -- and what order they occur in. Bill
Looking at the buildbots today, Windows is still unhappy. It seems to have gotten further, though. The problematic test is this one: File "C:\buildbot_py25\trunk.mcintyre-windows\build\lib\test\test_ssl.py", line 77, in testSSLconnect s.connect(("pop.gmail.com", 995)) File "C:\buildbot_py25\trunk.mcintyre-windows\build\lib\ssl.py", line 170, in connect if self._sslobj or (self.getsockname()[1] != 0): File "<string>", line 1, in getsockname error: (10022, 'Invalid argument') Looks like a valid complaint, actually. It should probably read if self._sslobj or (int(getnameinfo(self.getsockname(), 0)[1]) != 0): where "getnameinfo" is from the socket module. We're trying to see if the socket has been bound or connected already. I'm loath to generate a patch till I actually try this on a Windows machine. So I'm going to try that this afternoon, and generate a new patch for you. Bill
Actually, I think this is a bug in the Windows implementation of the socket interface. The question is, what should s.getsockname() return (or throw) if called on an unbound socket instance? Unix decided one way, and Windows another (and not a particularly good way). I'll post an issue to the tracker. Bill
Yes, the patch I sent out should fix that. I'd like to know, for the machines where the test is failing, what's in the generated cert file -- should be an RSA PRIVATE KEY and a CERTIFICATE -- and what order they occur in. Bill
Looking at the buildbots today, Windows is still unhappy. It seems to have gotten further, though. The problematic test is this one: File "C:\buildbot_py25\trunk.mcintyre-windows\build\lib\test\test_ssl.py", line 77, in testSSLconnect s.connect(("pop.gmail.com", 995)) File "C:\buildbot_py25\trunk.mcintyre-windows\build\lib\ssl.py", line 170, in connect if self._sslobj or (self.getsockname()[1] != 0): File "<string>", line 1, in getsockname error: (10022, 'Invalid argument') Looks like a valid complaint, actually. It should probably read if self._sslobj or (int(getnameinfo(self.getsockname(), 0)[1]) != 0): where "getnameinfo" is from the socket module. We're trying to see if the socket has been bound or connected already. I'm loath to generate a patch till I actually try this on a Windows machine. So I'm going to try that this afternoon, and generate a new patch for you. Bill
Actually, I think this is a bug in the Windows implementation of the socket interface. The question is, what should s.getsockname() return (or throw) if called on an unbound socket instance? Unix decided one way, and Windows another (and not a particularly good way). I'll post an issue to the tracker. Bill
participants (2)
-
Bill Janssen -
Neal Norwitz