apt-get install openssl will fix that on those systems. on windows
you're unlikely to ever have an openssl binary present and available to
execute.
OTOH, having openssl(1) installed is not a prerequisite for Python
buildbots currently, and IMO shouldn't be.
Regards,
Martin
Bill Janssen schrieb:
Well, that's just what you get with two independent implementations of
a spec. We don't try to hide the differences between the sockets stack
in Unix and Windows -- you'll just have to work around it.
No problem. But I think it's still a bug -- the spec (where is it?)
I think the spec would be the socket API. For sockets, that is POSIX.
According to
http://www.opengroup.org/pubs/online/7908799/xns/getsockname.html
the result is unspecified if the socket has not been bound to a local
name.
However, Windows does not implement POSIX here; instead, it
All right, this is committed. Let's see if the Windows buildbots like
it.
Bill
So, the patch is attached to issue 1052. I sent it out to python-dev,
but it got blocked (too big).
http://bugs.python.org/file8352/ssl-patch-5
This contains a number of things:
1) Improve the
Yes, the Windows buildbots seem happy now with ssl. I'm going to
expand the test suite.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On Sun, 26 Aug 2007, Bill Janssen wrote:
This must be the call to os.system in test_ssl.py:create_cert_files().
It's very UNIX-y. Can any bi-platform folks suggest a good
alternative to
os.system(
openssl req -batch -new -x509 -days 10 -nodes -config %s
-keyout \%s\
On Sun, 26 Aug 2007, Bill Janssen wrote:
This must be the call to os.system in test_ssl.py:create_cert_files().
It's very UNIX-y. Can any bi-platform folks suggest a good
alternative to
os.system(
openssl req -batch -new -x509 -days 10 -nodes -config %s
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
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
On 8/28/07, Bill Janssen [EMAIL PROTECTED] wrote:
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
Well, that's just what you get with two independent implementations of
a spec. We don't try to hide the differences between the sockets stack
in Unix and Windows -- you'll just have to work around it.
No problem. But I think it's still a bug -- the spec (where is it?)
should say what we want.
So, the patch is attached to issue 1052. I sent it out to python-dev,
but it got blocked (too big).
http://bugs.python.org/file8352/ssl-patch-5
This contains a number of things:
1) Improve the documentation of the SSL module, with a fuller
explanation of certificate usage, another
Hi Bill,
I think it's time you get to do your own checkins. There's a protocol
but I forget how to do it -- I think you mail your ssh key to Martin.
--Guido
On 8/28/07, Bill Janssen [EMAIL PROTECTED] wrote:
So, the patch is attached to issue 1052. I sent it out to python-dev,
but it got
Bill,
Please mail your ssh key as an attachment to [EMAIL PROTECTED]
n
--
On 8/28/07, Guido van Rossum [EMAIL PROTECTED] wrote:
Hi Bill,
I think it's time you get to do your own checkins. There's a protocol
but I forget how to do it -- I think you mail your ssh key to Martin.
--Guido
On
nope, not on many package based distributions. libssl0.9.8, libssl-dev and
openssl are all separate packages (with appropriate dependencies).
/usr/bin/openssl comes from the openssl package.
Regardless, building a fixed test certificate and checking it in sounds like
the better option. Then the
apt-get install openssl will fix that on those systems. on windows you're
unlikely to ever have an openssl binary present and available to execute.
Well, if you have OpenSSL in the first place, you'll have the binary,
won't you? But I agree it's unlikely to be on your path. As for Ubuntu
Regardless, building a fixed test certificate and checking it in sounds like
the better option. Then the openssl command in the test code can be turned
into a comment describing how the test data was pregenerated.
Here's a patch that does that.
Bill
Index: Lib/test/keycert.pem
Committed revision 57561.
On 8/27/07, Bill Janssen [EMAIL PROTECTED] wrote:
Regardless, building a fixed test certificate and checking it in sounds like
the better option. Then the openssl command in the test code can be turned
into a comment describing how the test data was pregenerated.
Some of the code sets the error string in this directly before
returning NULL, and other pieces of the code call PySSL_SetError,
which creates the error string. I think some of the places which set
the string directly probably shouldn't; instead, they should call
PySSL_SetError to cons up
Committed revision 57568.
Anything else I can check in for you?
On 8/27/07, Bill Janssen [EMAIL PROTECTED] wrote:
Some of the code sets the error string in this directly before
returning NULL, and other pieces of the code call PySSL_SetError,
which creates the error string. I think some
Anything else I can check in for you?
Ho, ho!
No, I'm done for now. I think everything is working; let's see what
the buildbots say. I've got to do some job work now, and I promised
Barry I'd help with the email work, but I'll get back to this with a
port to the Py3K branch. I'd also like to
This occurs on at least 3 of the buildbots (ubuntu and debian on ia64,
ppc, and hppa). Here's one example:
Unfortunately, I don't have Ubuntu or Debian machines. But I'd bet
it's a variation in the specific version of OpenSSL being used. I
just tested on Fedora Core 7, though, and test_ssl
This occurs on at least 3 of the buildbots (ubuntu and debian on ia64,
ppc, and hppa). Here's one example:
http://python.org/dev/buildbot/all/ia64%20Ubuntu%20trunk%20trunk/builds/832/step-test/0
If I'm reading this right, it's passing tests on amd64 gentoo trunk,
x86 gentoo trunk, g4 osx.4
On 8/26/07, Bill Janssen [EMAIL PROTECTED] wrote:
This occurs on at least 3 of the buildbots (ubuntu and debian on ia64,
ppc, and hppa). Here's one example:
http://python.org/dev/buildbot/all/ia64%20Ubuntu%20trunk%20trunk/builds/832/step-test/0
If I'm reading this right, it's passing
But I think this exposes a more generic bug in test_ssl.py, which is
that the server thread doesn't die when one of these failures occurs.
It probably should. I'll make a patch -- but I don't have a system
that this fails on, how will I test it?
Here's a patch which makes test_ssl a better
No need, I've submitted this for you. Fingers crossed.
On 8/26/07, Bill Janssen [EMAIL PROTECTED] wrote:
But I think this exposes a more generic bug in test_ssl.py, which is
that the server thread doesn't die when one of these failures occurs.
It probably should. I'll make a patch -- but I
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.
Yes, the patch I sent out should
Well, as long as you have your ears on, here's another patch to test_ssl.
1) Fixes the bug that two class names are initial-lower-case.
2) Replaces the poll waiting for the server to become ready with
a threading.Event signal.
Bill
Index: Lib/test/test_ssl.py
Thanks. I applied it. -- n
On 8/26/07, Bill Janssen [EMAIL PROTECTED] wrote:
Well, as long as you have your ears on, here's another patch to test_ssl.
1) Fixes the bug that two class names are initial-lower-case.
2) Replaces the poll waiting for the server to become ready with
a
Traceback (most recent call last):
File /home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/threading.py,
line 486, in __bootstrap_inner
self.run()
File
/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/test/test_ssl.py,
line 144, in run
Now it looks as if both the Debian and Ubuntu failures are failing
because they can't create a certificate, just like the Windows test.
I'll go out on a limb here and guess that it's because openssl isn't
on the path of the user running the tests.
That would also account for the other stack
Here's a patch that will turn the buildbots green, by not trying the
connected tests if the certificate can't be created. It also shows
the created cert if run in verbose mode.
We still need a working os.system command for Windows.
Bill
Index: Lib/test/test_ssl.py
apt-get install openssl will fix that on those systems. on windows you're
unlikely to ever have an openssl binary present and available to execute.
On 8/26/07, Bill Janssen [EMAIL PROTECTED] wrote:
Now it looks as if both the Debian and Ubuntu failures are failing
because they can't create a
I've gone through the other open SSL issues. Looks like some can be
closed with the adoption of 1018 and 1024:
1027394 4 months agosocket.ssl should explain that it is a 2/3 connection
889813 4 months agomaking the version of SSL configurable when creating
sockets
1583946 9 months ago
Bill,
Could you also look into this problem:
Traceback (most recent call last):
File /home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/threading.py,
line 486, in __bootstrap_inner
self.run()
File
/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/test/test_ssl.py,
line 144,
35 matches
Mail list logo
