Changes by Bill Janssen:
--
nosy: +janssen
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1018
__
___
Python-bugs-list mailing list
Unsubscribe:
http
New submission from Bill Janssen:
Here's a documentation patch for the SSL code that was checked in
yesterday. It removes discussion of SSL from the socket documentation,
makes a change to the urllib2 doc's discussion of how to test for SSL
support, and adds documentation of the SSL module
Bill Janssen added the comment:
Sorry, long day: ...and its features...
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1024
__
___
Python-bugs-list mailing list
Unsubscribe
Changes by Bill Janssen:
--
components: +Documentation
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1024
__
___
Python-bugs-list mailing list
Unsubscribe:
http
Bill Janssen added the comment:
I believe this is now fixed with patch 1018.
--
nosy: +janssen
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1114345
Bill Janssen added the comment:
Patch 1024 is new documentation which addresses this. Is is sufficient?
--
nosy: +janssen
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1027394
Bill Janssen added the comment:
I believe issue 1018 now fixes this.
--
nosy: +janssen
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue889813
___
Python-bugs-list
Bill Janssen added the comment:
I believe issue 1018 addressed this, and that it can be closed. Though
socket.ssl, and its methods server and issuer, should be deprecated.
--
nosy: +janssen
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org
Bill Janssen added the comment:
This probably needs to be re-written with the new SSL support in 2.6.
See issue 1024.
--
nosy: +janssen
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1217246
Bill Janssen added the comment:
I believe issue 1018 renders this one moot. Though more examples in Demo
is still a good idea. I'll contribute a threaded server example for
that.
--
nosy: +janssen
Tracker [EMAIL PROTECTED]
http://bugs.python.org
Bill Janssen added the comment:
It's not clear to me that having the SSL errors inherit from socket.error
is a good idea. Many of them have nothing to do with the socket, but are
errors in choice of cipher, certificate validation, etc.
--
nosy: +janssen
New submission from Bill Janssen:
The behavior and return value for calling socket.socket.getsockname() on
an unconnected unbound socket is unspecified. On UNIX, it returns an
address ('0.0.0.0', 0), while on Windows it raises an obscure exception
error: (10022, 'Invalid argument
New submission from Bill Janssen:
Just a note that the certificate in Lib/test/test_ssl.py will expire in
February of 2013 and have to be re-made.
--
components: Tests
messages: 55393
nosy: janssen
priority: low
severity: minor
status: open
title: certificate in Lib/test/test_ssl.py
Bill Janssen added the comment:
I'll take a look at this.
--
assignee: - janssen
nosy: +janssen
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1535659
Bill Janssen added the comment:
Checked in.
--
assignee: nnorwitz - janssen
resolution: - accepted
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1052
Bill Janssen added the comment:
Actually, looking at it further, I'm not sure that it is fixed by the new
SSL code. If in fact the issuer or subject field can contain multiple
name-value pairs with the same name, the dictionary-based approach
currently used won't work. We'll need more
Bill Janssen added the comment:
I'll take on providing the server example.
--
assignee: akuchling - janssen
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue783188
Bill Janssen added the comment:
Fixed with 2.6 SSL support.
--
resolution: - fixed
status: open - closed
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue889813
Bill Janssen added the comment:
Fixed with the 2.6 SSL work.
--
resolution: - fixed
status: open - closed
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1027394
Bill Janssen added the comment:
Fixed in 2.6.
--
resolution: - fixed
status: open - closed
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1114345
_
___
Python
Bill Janssen added the comment:
The new SSL code does work with self-signed certs, either by skipping
validation with CERT_NONE, or by adding the cert to the ca_certs file. I
don't believe there are any other options that make sense, but if you can
suggest one, let's hear
New submission from Bill Janssen:
It would be useful to have a way to determine whether a socket is or is
not already bound to a local port (i.e., has had bind or connect
called on it). It's tempting to call socket.socket.getsockname(), but
the behavior of this method is essentially
Bill Janssen added the comment:
What happened to my issue metadata?
--
assignee: - janssen
priority: - low
title: None - nice to have a way to tell if a socket is bound
type: - rfe
versions: +Python 2.6, Python 3.0
__
Tracker [EMAIL PROTECTED]
http
Bill Janssen added the comment:
Indeed. Calls for some design chops. Again, it's a question of what
the socket.socket class really is.
Bill
On 8/30/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
Martin v. Löwis added the comment:
Given that the underlying platform has no support
New submission from Bill Janssen:
It seems like a bad idea to have ssl.sslsocket(socket) suddenly become
ssl.SSLSocket(fileno) in 2.3. Since no user code is currently using the
ssl module, it would be a good idea to change it upfront (if possible)
so that code written against 2.6's version
Bill Janssen added the comment:
I agree. It shouldn't be an absolute size, and it is too small.
--
nosy: +janssen
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1072
Bill Janssen added the comment:
Wow. I think that platform.system() should return Windows for both XP
and Vista, and platform.release() should return either Vista or XP.
Seems like a patch to make this happen would be a good idea.
--
nosy: +janssen
Bill Janssen added the comment:
I'm planning to do a package for 2.3...
Sent from my iPhone
On Sep 3, 2007, at 5:32 AM,
vila-sf
[EMAIL PROTECTED] wrote:
vila-sf
added the comment:
Using CERT_NONE or adding the cert covers my needs, thanks.
Any hope
Bill Janssen added the comment:
I've changed the return value of ssl.sslsocket.getpeercert() to return the
issuer and subject names as tuples containing 2-element name-value
tuples, in the same order that they appear in the certificate. This
should complete the fulfillment of this issue
Bill Janssen added the comment:
Which versions of OS X, please? And which Xcode versions?
--
nosy: +janssen
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1099
Bill Janssen added the comment:
Isn't this 1094?
--
nosy: +janssen
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1132
__
___
Python-bugs-list mailing list
Unsubscribe
Bill Janssen added the comment:
I think the example in Lib/test/test_ssl.py will have to suffice.
It would be nice to have an asyncore example server, too.
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue783188
Bill Janssen added the comment:
Fixed in rev 58097.
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1583946
_
___
Python-bugs-list mailing list
Unsubscribe:
http
Changes by Bill Janssen:
--
resolution: - fixed
status: open - closed
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1583946
_
___
Python-bugs-list mailing list
Bill Janssen added the comment:
Fixed in rev 58097.
--
resolution: - fixed
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1065
__
___
Python-bugs
Bill Janssen added the comment:
Georg got it right -- this patch is bogus. I'm going to close it as
won't fix. Feel free to re-open it as an RFE with a good patch.
--
resolution: - wont fix
status: open - closed
_
Tracker [EMAIL PROTECTED]
http
New submission from Bill Janssen:
If you build Python with --disable-toolbox-glue on OS X, the attempt to
import ctypes fails because it critically depends on gestalt, one of
the modules in the toolbox. It only uses this to check whether the OS
level is 10.4 or something earlier, and only
Bill Janssen added the comment:
Here's a patch against the trunk. I've only tried it on OS X 10.4.10, and
only with test_ctypes. Ideally, we should test on an earlier version of
OS X, but I don't have one handy.
__
Tracker [EMAIL PROTECTED]
http
Bill Janssen added the comment:
Sorry, you're absolutely right. Here's a corrected patch.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1203
__
p
Description: Binary data
Changes by Bill Janssen:
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1203
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python
Bill Janssen added the comment:
Yes, that works too. It seems to be another way of accessing
the same information; it's not clear to me which is preferable.
Bill
On 9/25/07, Thomas Heller [EMAIL PROTECTED] wrote:
Thomas Heller added the comment:
This patch looks better. However
Bill Janssen added the comment:
By a bit of synchronicity, I've been looking at non-blocking SSL issues
all day. Thanks, Chris. I'll take a look and fold it in. There are a
number of other issues here, too, such as changing the socket's blocking-
ness after it's wrapped (which asyncore does
Bill Janssen added the comment:
The larger problem here is that straightforward select() just doesn't
work with SSL-wrapped sockets. If you depend on it for liveness, your
program will eventually hang up.
When packets in SSL arrive at a destination, they are pulled off the
socket in chunks
Bill Janssen added the comment:
SSL-wrapped sockets *must* be set non-blocking.
Can you say a bit more about why?
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1251
Bill Janssen added the comment:
Yes, that's correct.
I've reviewed your patch, and it looks OK to me. I'll fold it in in the
next go-around, once I've made some progress on the asyncore issues.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1251
Bill Janssen added the comment:
Chris,
Looking at this a bit harder, I don't see that it accomplishes much.
The loop in _ssl.c/do_handshake will never return WANT_READ or
WANT_WRITE, so the loop in the test case, for instance, is unnecessary.
The original code handled the non-blocking case
Bill Janssen added the comment:
It's my mistake; I was looking at too many patches at the same time.
Thanks for the example.
Bill
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1251
Bill Janssen added the comment:
See the SSL package on PyPI. Should work on 2.3, 2.4, and 2.5.
Bill
On 10/14/07, vila [EMAIL PROTECTED] wrote:
vila added the comment:
I'm planning to do a package for 2.3...
Any progress on that package ?
I'd like to do the same for python 2.4 and 2.5
Bill Janssen added the comment:
Perhaps we shouldn't expose this at the application level. We could
check, in the C module's sslwrap, whether the socket is blocking or not,
and do the right thing there, so that sslwrap would always succeed in
one call. Since we are releasing the GIL
Bill Janssen added the comment:
You seem to be missing the whole point of doing non-blocking I/O,
You know, I think that's right. I'm so used to using threads by now
that the whole select-based approach seems very odd to me by now.
OK, I've folded your patch into the PyPI version, ssl 1.8
New submission from Bill Janssen:
A number of places in the BaseHTTPServer got missed when converting
between bytes and strings. Here's a patch to fix that.
--
components: Library (Lib)
files: a
messages: 56868
nosy: janssen
severity: normal
status: open
title: BaseHTTPServer writing
New submission from Bill Janssen:
I can't get urllib.urlopen() to work with SSL, and it seems to be due to
a bug in the re-write of httplib. HTTPConnection.getresponse() is
closing the socket, but then returning a response object holding onto
that closed socket to the caller, who then tries
Bill Janssen added the comment:
I believe this is all that's needed.
Added file: http://bugs.python.org/file8638/c
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1348
__
c
Description: Binary data
New submission from Bill Janssen:
Neal, a patch to get rid of the other ord() calls in ic.py.
--
assignee: nnorwitz
components: Library (Lib), Macintosh
files: d
keywords: py3k
messages: 56872
nosy: janssen, nnorwitz
priority: high
severity: normal
status: open
title: more uses of ord
Bill Janssen added the comment:
I still think the semantics are wrong here, but someone needs to close
this connection at some point, and right now the reference-counting
semantics of socket.close() are the only thing preventing a leak. So I
think my patch should not be applied. Instead
Bill Janssen added the comment:
Will do.
On 10/29/07, Guido van Rossum [EMAIL PROTECTED] wrote:
Guido van Rossum added the comment:
Looks good. You can check this in yourself right?
--
assignee: - janssen
nosy: +gvanrossum
resolution: - accepted
Bill Janssen added the comment:
I've been testing it over the weekend. Will do.
Bill
On 10/29/07, Guido van Rossum [EMAIL PROTECTED] wrote:
Guido van Rossum added the comment:
Looks good, though I can't find anything that would test this.
Can you check this in yourself
Bill Janssen added the comment:
Fixed in rev 58718
--
keywords: +py3k
resolution: accepted - fixed
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1347
Bill Janssen added the comment:
Fixed in r58717
--
resolution: - fixed
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1349
__
___
Python-bugs
Bill Janssen added the comment:
Good catch. I found this in the 3K branch, but hadn't backported it to
the SSL PyPI module yet.
--
resolution: - accepted
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1419
Bill Janssen added the comment:
I've uploaded a fixed ssl-1.12 to PyPI.
--
resolution: accepted - fixed
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1419
New submission from Bill Janssen:
This patch essentially makes GC of sockets work again.
See http://mail.python.org/pipermail/python-3000/2007-October/
011058.html and all the threads in http://mail.python.org/pipermail/
python-3000/2007-October/thread.html with subject line socket GC
worries
Bill Janssen added the comment:
Once I've tried it again.
Bill
On Nov 14, 2007 2:32 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
Guido van Rossum added the comment:
Committed revision 58970 (with slight changes).
Bill, you can now submit your SSL code for review.
--
assignee
Bill Janssen added the comment:
I've tried several different times to fix that warning. It appears on
some releases of gcc, and not on others. There seems to be no cast or
declaration that fixes it everywhere. More power to you if you can
find one!
Bill
On 11/15/07, Christian Heimes [EMAIL
Bill Janssen added the comment:
Actually, it's some combination of the version of OpenSSL plus the
version of gcc.
Bill
On 11/15/07, Bill Janssen [EMAIL PROTECTED] wrote:
I've tried several different times to fix that warning. It appears on
some releases of gcc, and not on others
Bill Janssen added the comment:
I'll check it in this afternoon -- I've just got to figure out how to
run the Python clean-up tool. Then you can check in the socket3.diff
patch, then I'll make sure the SSL module works with that version of
sockets.
Bill
On 11/15/07, Guido van Rossum [EMAIL
Bill Janssen added the comment:
OK, it's checked in. Let's see what the Windows buildbots think :-).
Bill
On Nov 15, 2007 1:35 PM, Bill Janssen [EMAIL PROTECTED] wrote:
Bill Janssen added the comment:
I'll check it in this afternoon -- I've just got to figure out how to
run the Python
Bill Janssen added the comment:
Looks like the Python SVN cert did not get included in the patch, which
is causing a failure. I'll check that in.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1451
Bill Janssen added the comment:
This is now checked into the 3K branch.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1251
__
___
Python-bugs-list mailing list
Unsubscribe
New submission from Bill Janssen:
I'm seeing leaks in the test_ssl run, after various socket.py changes.
I'm looking into it.
--
assignee: janssen
components: Library (Lib)
keywords: py3k
messages: 57667
nosy: janssen
severity: normal
status: open
title: SSL tests leak memory
versions
Bill Janssen added the comment:
Looks good to me, too.
--
nosy: +janssen
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1468
__
___
Python-bugs-list mailing list
Bill Janssen added the comment:
What platform?
Bill
On Nov 20, 2007 11:21 PM, Christian Heimes [EMAIL PROTECTED] wrote:
Christian Heimes added the comment:
I don't see leaks when I run the tests with
$ ./python Lib/test/regrtest.py -R:: test_ssl.py
test_ssl
beginning 9 repetitions
Bill Janssen added the comment:
I'll take a look at it this weekend.
Bill
On Nov 21, 2007 1:27 AM, Christian Heimes [EMAIL PROTECTED] wrote:
New submission from Christian Heimes:
The SSL version of the imap4 client isnt' working under 3.0. After I
applied the patch from http
Bill Janssen added the comment:
Yes. The close is stil in the wrong place.
On Nov 21, 2007 2:30 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
Guido van Rossum added the comment:
Is this still relevant?
--
assignee: - janssen
priority: urgent - normal
Bill Janssen added the comment:
No, the close must be removed. It's the wrong *way* to transfer
responsibility. Close means close, not I wash my hands of
responsibility here. What's hidden here is that the open socket is
transferred to the response, which continues to use it. In fact
Bill Janssen added the comment:
That's because the socket.py code has been adapted (the first word I wrote
there was perverted :--) to deal with this case. That is, the close() has
been rendered meaningless because of the explicit reference counting in
socket.py. But the right solution
Bill Janssen added the comment:
I'm seeing the leaks on my Leopard machine. I haven't had a chance to look
into it yet.
On Dec 1, 2007 11:20 AM, Christian Heimes [EMAIL PROTECTED] wrote:
Christian Heimes added the comment:
Are you sure that the SSL tests are still leaking memory
Bill Janssen added the comment:
I'm still not sure what the problem is. This code was working fine when I
committed it, no leaks, so something else must have changed under the
covers. I don't believe that adding GC to the C code is the answer; it
should be automatically GC'd. So I'd back
Bill Janssen added the comment:
I think I've figured it out. My initial patch to socket.py and ssl.py
had an extra method defined on socket.socket, _real_close(), which did'
the cleanup work of deallocating the underlying socket, and in the SSL
subclass, of releasing the SSL context. Guido
Bill Janssen added the comment:
So, what's the final status of __del__ in py3K? The other bit of leak
is due to _real_close() not being called when a socket is dropped on the
floor (say, you try to connect, fail, and raise the exception back to
the caller, without ever explicitly calling close
Bill Janssen added the comment:
The other leak comes from this code:
s = ssl.wrap_socket(socket.socket(), ...)
s.connect((SOME BOGUS ADDRESS OR SERVER))
The connect() fails, and the SSLSocket sgets dropped on the floor,
but never seems to be GC'd, (or the GC never seems to call
Bill Janssen added the comment:
gc.garbage is always empty.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1469
__
___
Python-bugs-list mailing list
Unsubscribe:
http
Bill Janssen added the comment:
Ah, I see what's going on. The revision of the socket code (nice job,
by the way) removed the distinction between the C socket object and the
Python socket object. The C SSLContext keeps a pointer to the C socket
object, which is now the Python socket object
Bill Janssen added the comment:
I think Christian analysis is right, in that it takes a bit of GC
support, but not perhaps in the specifics of his approach. I've done
two things to fix this:
1) Put _real_close() back in socket.py, and then override it in
ssl.SSLSocket to release
Bill Janssen added the comment:
Here's a patch -- take a look and let me know.
I also added a real asyncore server test.
Added file: http://bugs.python.org/file8919/a
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1469
Bill Janssen added the comment:
I'm still getting this with the latest SSL module fixes. I'm guessing
this is a problem with the implementation of imaplib, but I haven't
looked into it yet.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1482
Bill Janssen added the comment:
Here's a fix for the 3K branch.
Added file: http://bugs.python.org/file8921/b
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1482
__
b
Description: Binary data
Changes by Bill Janssen:
--
keywords: +patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1482
__
___
Python-bugs-list mailing list
Unsubscribe:
http
Bill Janssen added the comment:
Now, about the confused signature of SSLSocket.read().
I'm not sure how confused it is. It's sui generis; SSLSocket doesn't
inherit from some other class with a different read() method with a
different signature. But we could change the name, perhaps
Changes by Bill Janssen:
Removed file: http://bugs.python.org/file8919/a
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1469
__
___
Python-bugs-list mailing list
Unsubscribe
Bill Janssen added the comment:
Unfortunately, hostname matching is one of those ideas that seemed
better when it was thought up than it actually proved to be in practice.
I've had extensive experience with this, and have found it to almost
always an application-specific decision. I thought
Bill Janssen added the comment:
Yes, I think that's reasonable. And for pseudo-standards like https, which
calls for this, the implementation in the standard library should attempt to
do it automatically. Unfortunately, that means that client-side certificate
verification has to be done (it's
Bill Janssen added the comment:
The mechanism is there for direct use of the SSL module, yes. But the
question is, what should indirect usage, like the httplib or urllib modules,
do? If they are going to check hostnames on use of an https: URL, they need
some way to pass a ca_certs file
Bill Janssen added the comment:
Good catch. I flipped a bit cleaning up the C code.
Here's a fixed patch.
Added file: http://bugs.python.org/file8949/patch-3
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1469
Bill Janssen added the comment:
The server isn't handling the close event properly. I'll fix that.
On Dec 13, 2007 9:06 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
Guido van Rossum added the comment:
I spoke too soon. In a debug build, this hangs forever during the
second iteration
Bill Janssen added the comment:
Here's an update version where the asyncore test server properly handles
the EOF race condition.
Added file: http://bugs.python.org/file8955/patch-4
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1469
Changes by Bill Janssen:
Removed file: http://bugs.python.org/file8949/patch-3
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1469
__
___
Python-bugs-list mailing list
Changes by Bill Janssen:
Removed file: http://bugs.python.org/file8954/unnamed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1469
__
___
Python-bugs-list mailing list
Bill Janssen added the comment:
Done.
On Dec 14, 2007 9:44 AM, Guido van Rossum [EMAIL PROTECTED] wrote:
Guido van Rossum added the comment:
Here's an update version where the asyncore test server properly handles
the EOF race condition.
Perfect! Check
Bill Janssen added the comment:
Considering that HTTPSConnection uses the exact same code as
HTTPConnection to interpret the specified address, I think we need more
diagnosis in order to determine whether this is a real issue or not. If
it is, what's going wrong
1 - 100 of 295 matches
Mail list logo
