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:
http://mail.python.org/mailman/options/python
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 docu
> 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; ins
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
> 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,
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.
>
> --Gui
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 b
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 reference,
> 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 w
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 "C:\buildbot_py25\trunk.mcintyre
> 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._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 "C:\buildbo
> 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 "
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 "
> "-key
> 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
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 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 u
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 pregen
> 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
===
> 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
a
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.
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 crea
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
=
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 trac
> 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
> cert_reqs=self.ser
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
>
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
=
> 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
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 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 bette
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
> 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", "g
> 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
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
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
35 matches
Mail list logo
