[issue1018] server-side ssl support
Changes by Bill Janssen: -- nosy: +janssen __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1018> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1024] documentation for new SSL module
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 and it's features, including some examples of how to use it. -- files: x2 keywords: patch messages: 55293 nosy: janssen priority: normal severity: normal status: open title: documentation for new SSL module type: rfe versions: Python 2.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1024> __ x2 Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1024] documentation for new 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: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1024] documentation for new SSL module
Changes by Bill Janssen: -- components: +Documentation __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1024> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1114345] Add SSL certificate validation
Bill Janssen added the comment: I believe this is now fixed with patch 1018. -- nosy: +janssen _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1114345> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1027394] socket.ssl should explain that it is a 2/3 connection
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> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue889813] making the version of SSL configurable when creating sockets
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 mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1583946] SSL "issuer" and "server" names cannot be parsed
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/issue1583946> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1217246] proposed patch for tls wrapped ssl support added to smtplib
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> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue783188] support for server side transactions in _ssl
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/issue783188> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706815] socket.error exceptions not subclass of StandardError
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 _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1706815> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1049] socket.socket.getsockname() has inconsistent UNIX/Windows behavior
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')". This should be regularized; I'd
suggest returning None if there is no name (address) for the socket.
--
components: Library (Lib)
messages: 55390
nosy: janssen
priority: normal
severity: normal
status: open
title: socket.socket.getsockname() has inconsistent UNIX/Windows behavior
type: behavior
versions: Python 2.6, Python 3.0
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1049>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1051] certificate in Lib/test/test_ssl.py expires in February 2013
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 expires in February 2013 type: behavior versions: Python 2.6, Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1051> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1535659] NNTPS support in nntplib
Bill Janssen added the comment: I'll take a look at this. -- assignee: -> janssen nosy: +janssen _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1535659> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1052] SSL patch for Windows buildbots problem
Bill Janssen added the comment: Checked in. -- assignee: nnorwitz -> janssen resolution: -> accepted status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1052> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1583946] SSL "issuer" and "server" names cannot be parsed
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 of an alist approach, with name-value tuples in it. I'd better look into this. -- assignee: -> janssen _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1583946> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue783188] support for server side transactions in _ssl
Bill Janssen added the comment: I'll take on providing the server example. -- assignee: akuchling -> janssen Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue783188> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue889813] making the version of SSL configurable when creating sockets
Bill Janssen added the comment: Fixed with 2.6 SSL support. -- resolution: -> fixed status: open -> closed Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue889813> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1027394] socket.ssl should explain that it is a 2/3 connection
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> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1114345] Add SSL certificate validation
Bill Janssen added the comment: Fixed in 2.6. -- resolution: -> fixed status: open -> closed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1114345> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1114345] Add SSL certificate validation
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 it. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1114345> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1062] issue message copy
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 undefined (i.e., it's whatever the underlying platform feels like doing, and there seem to be no constraints on that -- Unix systems typically return what seems to be someone's idea of a null address, while Windows systems currently raise an exception.). So an extension API is needed to probe this state. Suggest adding a method "is_bound" which returns a boolean. -- messages: 55494 nosy: janssen severity: normal status: open __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1062> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1062] nice to have a way to tell if a socket is bound
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://bugs.python.org/issue1062> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1062] nice to have a way to tell if a socket is bound
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 for that, it will be > difficult to implement correctly across all systems. > > -- > nosy: +loewis > > __ > Tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue1062> > __ > __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1062> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1065] ssl.py shouldn't change class names from 2.6 to 3.x
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 of the ssl module doesn't break gratuitously in 3.x. Would suggest changing the class name now, not documenting the initializer, and adding a function (say, "wrap_socket") which takes a socket and the other init arguments to the current ssl.sslsocket(), which would continue to work the same way in 3.x. -- assignee: janssen components: Library (Lib) keywords: py3k messages: 55516 nosy: janssen priority: normal severity: normal status: open title: ssl.py shouldn't change class names from 2.6 to 3.x type: behavior versions: Python 2.6, Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1065> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1072] Documentaion font size too small
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> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1082] platform system may be Windows or Microsoft since Vista
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 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1082> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1114345] Add SSL certificate validation
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 this will be backported to python 2.5 ? > > _ > Tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue1114345> > _ _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1114345> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1583946] SSL "issuer" and "server" names cannot be parsed
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. Please see the doc page on library/ssl.rst for more information. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1583946> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1099] Mac compile fails with pydebug and framework enabled
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> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1132] compile error in poplib.py
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: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue783188] support for server side transactions in _ssl
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> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1583946] SSL "issuer" and "server" names cannot be parsed
Bill Janssen added the comment: Fixed in rev 58097. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1583946> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1583946] SSL "issuer" and "server" names cannot be parsed
Changes by Bill Janssen: -- resolution: -> fixed status: open -> closed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1583946> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1065] ssl.py shouldn't change class names from 2.6 to 3.x
Bill Janssen added the comment: Fixed in rev 58097. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1065> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1535659] NNTPS support in nntplib
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://bugs.python.org/issue1535659> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1203] ctypes doesn't work on Mac with --disable-toolbox-glue
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 once, at load. Might be a good idea to substitute a check which doesn't require the toolbox, such as looking at platform.release(). -- components: Library (Lib), Macintosh messages: 56132 nosy: janssen severity: normal status: open title: ctypes doesn't work on Mac with --disable-toolbox-glue type: behavior versions: Python 2.6, Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1203> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1203] ctypes doesn't work on Mac with --disable-toolbox-glue
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://bugs.python.org/issue1203> __ p Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1203] ctypes doesn't work on Mac with --disable-toolbox-glue
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 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1203] ctypes doesn't work on Mac with --disable-toolbox-glue
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-bugs-list/archive%40mail-archive.com
[issue1203] ctypes doesn't work on Mac with --disable-toolbox-glue
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, the 'os.uname()' function seems to > return the information that we need; so I updated the patch to use this > instead. Can you please proofread it (osx.patch) ? > > __ > Tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue1203> > __ > __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1203> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1251] ssl module doesn't support non-blocking handshakes
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). __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1251> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1251] ssl module doesn't support non-blocking handshakes
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 of sizes controlled by the encryption protocol being used, decrypted, and placed in SSL-internal buffers. The buffer content is then transferred to the application program through SSL_read(). If you've read only part of the decrypted data, there will still be pending input data on the SSL connection, but it won't show up on the underlying file descriptor via select(). Your code needs to call SSL_pending() explicitly to see if there is any pending data to be read. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1251> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1251] ssl module doesn't support non-blocking handshakes
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> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1251] ssl module doesn't support non-blocking handshakes
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> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1251] ssl module doesn't support non-blocking handshakes
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 just fine. I think this fix is unnecessary. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1251> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1251] ssl module doesn't support non-blocking handshakes
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> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1114345] Add SSL certificate validation
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 as I have a need for it > for both versions. > > I don't know what you call a package though, but I'm willing to learn :) > > -- > nosy: +vila > > _ > Tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue1114345> > _ > _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1114345> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1251] ssl module doesn't support non-blocking handshakes
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 whenever we do SSL_accept() or SSL_connect(), other threads get a chance to run, so doing it transparently shouldn't affect the Python program's liveness. And it would reduce the chances for application error. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1251> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1251] ssl module doesn't support non-blocking handshakes
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. It will meander into the trunk and 3K version as well. Thanks for the help! Bill On 10/15/07, Chris Stawarz <[EMAIL PROTECTED]> wrote: > > Chris Stawarz added the comment: > > Bill, > > You seem to be missing the whole point of doing non-blocking I/O, > which is to handle multiple concurrent, I/O-bound tasks in a single > OS thread. The application must be able to try the handshake, detect > that it didn't complete because I/O needs to take place, and then > retry it at a later time of its choosing (presumably when select() > says it's OK to read from the socket). And between now and that > later time, it can do other things, like read or write to other sockets. > > The point is that the *application* must have control over when it > does I/O, when it waits for sockets to be ready for I/O, and what it > does in between. There's just no way it can do this if the sslwrap() > function doesn't return until the handshaking is complete. sslwrap() > can't "do the right thing", because the right thing is to return > control to the application until it's ready to try the handshake again. > > And this has nothing to do with the GIL or multiple threads. Like I > said, the point of doing non-blocking I/O with select() is to *avoid* > the need for multiple threads. > > __ > Tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue1251> > __ > __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1251> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1347] BaseHTTPServer writing strings to bytes interface
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 strings to bytes interface type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file8636/a __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1347> __ a Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1348] httplib closes socket, then tries to read from it
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 to read from the (closed) socket. Due to the delayed closing of sockets, this error is masked, but in SSL, the context is torn down on close, so we see real failures. -- components: Library (Lib) keywords: py3k messages: 56870 nosy: janssen priority: urgent severity: normal status: open title: httplib closes socket, then tries to read from it type: behavior versions: Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1348> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1348] httplib closes socket, then tries to read from it
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 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1349] more uses of ord() in plat-mac/ic.py
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() in plat-mac/ic.py type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file8639/d __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1349> __ d Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1348] httplib closes socket, then tries to read from it
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, a larger fix needs to be thought through, which will probably require some changes to urllib and its cousins. -- keywords: +patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1348> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1223] httplib does not handle ssl end of file properly
Bill Janssen added the comment: I have a slightly different version of this patch in the new SSL code. It (optionally, but defaulting to True) catches SSL_ERROR_EOF and returns None, but allows other ssl errors to go through. -- nosy: +janssen Added file: http://bugs.python.org/file8643/e __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1223> __ e Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1347] BaseHTTPServer writing strings to bytes interface
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 > > __ > Tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue1347> > __ > __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1347> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1349] more uses of ord() in plat-mac/ic.py
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? > > -- > assignee: nnorwitz -> janssen > nosy: +gvanrossum > > __ > Tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue1349> > __ > __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1349> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1347] BaseHTTPServer writing strings to bytes interface
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> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1349] more uses of ord() in plat-mac/ic.py
Bill Janssen added the comment: Fixed in r58717 -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1349> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1419] ssl module version 1.10 causes TypeError when accepting connection
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> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1419] ssl module version 1.10 causes TypeError when accepting connection
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> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1419] ssl module version 1.10 causes TypeError when accepting connection
Bill Janssen added the comment: About the same as two weeks ago... I have a functional patch, or rather, I have a patch that would work if the issues with socket closing are resolved the way I suggested :-). I've been waiting to see what's going to happen with the socket module. Bill On 11/12/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > Guido van Rossum added the comment: > > BTW Bill, how's the 3.0 port of SSL going? > > -- > nosy: +gvanrossum > > __ > Tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue1419> > __ > __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1419> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1439] proposed 3000 patch for socket.py - "socket GC worries"
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" for a full discussion. -- assignee: gvanrossum components: Library (Lib) files: b keywords: patch, py3k messages: 57470 nosy: gvanrossum, janssen severity: normal status: open title: proposed 3000 patch for socket.py - "socket GC worries" versions: Python 3.0 Added file: http://bugs.python.org/file8742/b __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1439> __ b Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1439] proposed 3000 patch for socket.py - "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: gvanrossum -> tiran > resolution: -> accepted > status: open -> closed > > > __ > Tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue1439> > __ > __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1439> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1451] SSL patch for Python 3000
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 PROTECTED]> wrote: > > Christian Heimes added the comment: > > Ubuntu Linux 7.10, x86, gcc version 4.1.3 20070929 (prerelease) (Ubuntu > 4.1.2-16ubuntu2) > > > /home/heimes/dev/python/py3k/Modules/_ssl.c: In function > '_get_peer_alt_names': > /home/heimes/dev/python/py3k/Modules/_ssl.c:680: warning: passing > argument 2 of 'ASN1_item_d2i' from incompatible pointer type > /home/heimes/dev/python/py3k/Modules/_ssl.c:684: warning: passing > argument 2 of 'method->d2i' from incompatible pointer type > gcc -pthread -shared > > -- > nosy: +tiran > > __ > Tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue1451> > __ > __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1451> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1451] SSL patch for Python 3000
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. 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 PROTECTED]> wrote: > > > > Christian Heimes added the comment: > > > > Ubuntu Linux 7.10, x86, gcc version 4.1.3 20070929 (prerelease) (Ubuntu > > 4.1.2-16ubuntu2) > > > > > > /home/heimes/dev/python/py3k/Modules/_ssl.c: In function > > '_get_peer_alt_names': > > /home/heimes/dev/python/py3k/Modules/_ssl.c:680: warning: passing > > argument 2 of 'ASN1_item_d2i' from incompatible pointer type > > /home/heimes/dev/python/py3k/Modules/_ssl.c:684: warning: passing > > argument 2 of 'method->d2i' from incompatible pointer type > > gcc -pthread -shared > > > > -- > > nosy: +tiran > > > > __ > > Tracker <[EMAIL PROTECTED]> > > <http://bugs.python.org/issue1451> > > __ > > > __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1451> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1451] SSL patch for Python 3000
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 PROTECTED]> wrote: > > Guido van Rossum added the comment: > > If you haven't checked this in by tomorrow morning, I'll submit issue > 1378 (socket3.diff) first, and you'll have to do a bunch of cleanup. > Or, if you like, I can submit that now and you can do the cleanup this > afternoon. (Basically, we can dup() sockets on Windows now, so all the > nonsense about keeping our own reference counts is no longer needed -- > makefile() just hangs on to a dup() of the socket. This restores the > semantics we had in 1.5.2... > > __ > Tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue1451> > __ > __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1451> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1451] SSL patch for Python 3000
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 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 PROTECTED]> wrote: > > > > > Guido van Rossum added the comment: > > > > If you haven't checked this in by tomorrow morning, I'll submit issue > > 1378 (socket3.diff) first, and you'll have to do a bunch of cleanup. > > Or, if you like, I can submit that now and you can do the cleanup this > > afternoon. (Basically, we can dup() sockets on Windows now, so all the > > nonsense about keeping our own reference counts is no longer needed -- > > makefile() just hangs on to a dup() of the socket. This restores the > > semantics we had in 1.5.2... > > > > __ > > Tracker <[EMAIL PROTECTED]> > > <http://bugs.python.org/issue1451> > > __ > > > > __ > Tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue1451> > __ > __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1451> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1451] SSL patch for Python 3000
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> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1251] ssl module doesn't support non-blocking handshakes
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: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1469] SSL tests leak memory
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: Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1469> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1468] MSI installer does not include SSL test .pem files
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 Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1469] SSL tests leak memory
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 > 123456789 > . > 1 test OK. > [80034 refs] > > -- > nosy: +tiran > priority: -> normal > > __ > Tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue1469> > __ > __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1469> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1482] IMAP4 SSL isn't working
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://bugs.python.org/issue1210 I tried to
> connect to an IMAP server over SSL. The connection hangs.
>
> import imaplib
> conn = imaplib.IMAP4_SSL("mailbox.rwth-aachen.de", 993)
>
> After a while I stopped the attempt with CTRL+C
> Traceback (most recent call last):
> File "", line 1, in
> File "/home/heimes/dev/python/py3k/Lib/imaplib.py", line 1137, in __init__
> IMAP4.__init__(self, host, port)
> File "/home/heimes/dev/python/py3k/Lib/imaplib.py", line 184, in __init__
> self.welcome = self._get_response()
> File "/home/heimes/dev/python/py3k/Lib/imaplib.py", line 907, in
> _get_response
> resp = self._get_line()
> File "/home/heimes/dev/python/py3k/Lib/imaplib.py", line 1000, in
> _get_line
> line = self.readline()
> File "/home/heimes/dev/python/py3k/Lib/imaplib.py", line 1170, in readline
> char = self.sslobj.read(1)
> File "/home/heimes/dev/python/py3k/Lib/ssl.py", line 160, in read
> return self._sslobj.read(len)
> KeyboardInterrupt
>
> --
> assignee: janssen
> components: Library (Lib)
> keywords: py3k
> messages: 57735
> nosy: janssen, tiran
> priority: normal
> severity: normal
> status: open
> title: IMAP4 SSL isn't working
> versions: Python 3.0
>
> __
> Tracker <[EMAIL PROTECTED]>
> <http://bugs.python.org/issue1482>
> __
>
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1482>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1348] httplib closes socket, then tries to read from it
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 > > __ > Tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue1348> > __ > __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1348> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1348] httplib closes socket, then tries to read from it
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, the close() should happen when the caller is finished with the response, probably as effect of the GC of the "response" object. On Nov 25, 2007 3:09 AM, vila <[EMAIL PROTECTED]> wrote: > > vila added the comment: > > The title of this bug is scary. > > httplib rightly close the socket because that's the way to transfer the > responsibility of the close to the user of the HttpResponse object. > > The close MUST stays there. > > I do encounter a bug related to that close while trying to use the ssl > module in python2.6. > > I'm willing to help fixing it but *this* bug may not be the right place > to do so (even if related). > > I'm a bit lost on how to help right now since the involved changes seems > to occur in both python3.0 and python2.6 and I'm currently targeting 2.4 > and 2.5. > > -- > nosy: +vila > > __ > Tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue1348> > __ > __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1348> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1348] httplib closes socket, then tries to read from it
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 is to not close the socket till the application is done with it; that is, transfer the responsibility for the socket to the part of the application which is still using it. I'm not sure that just fixing this one case will remove the need for the explicit reference counting in socket.py, but this is the case that I noticed. On Nov 26, 2007 1:11 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > Guido van Rossum added the comment: > > Bill, is there a code example that should work but breaks because of > that close()? ATM, there doesn't seem to be anything in the tests that > breaks... > > __ > Tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue1348> > __ > Added file: http://bugs.python.org/file8814/unnamed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1348> __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 is to not close the socket till the application is done with it; that is, transfer the responsibility for the socket to the part of the application which is still using it. I'm not sure that just fixing this one case will remove the need for the explicit reference counting in socket.py, but this is the case that I noticed.On Nov 26, 2007 1:11 PM, Guido van Rossum <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> wrote: Guido van Rossum added the comment:Bill, is there a code example that should work but breaks because ofthat close()? ATM, there doesn't seem to be anything in the tests thatbreaks... __Tracker <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]><http://bugs.python.org/issue1348"; target="_blank">http://bugs.python.org/issue1348 >__ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6560] socket sendmsg(), recvmsg() methods
Bill Janssen added the comment: I'm guessing these things are due to interaction with some Apple security update, as the buildbots were working well 8 months ago. Bill On Wed, Sep 7, 2011 at 4:01 PM, Nick Coghlan wrote: > > Nick Coghlan added the comment: > > If Bill gets a chance to investigate this before the weekend, great, > otherwise my plan to stop making noise in the buildbot results will be to: > > 1. Create a separate issue specifically for the errors reported by the Mac OS > X buildbots (allowing the problem to be spelled out more clearly for readers, > and also allowing the feature request itself to be closed) > > 2. Flag the offending tests as expected failures on Mac OS X, with a pointer > back to the new tracker issue. > > That way, if these failures are due to underlying OS bugs or limitations (as > they appear to be), we'll get a clear indication in the buildbots when Apple > have fixed the relevant problems. > > -- > > ___ > Python tracker > <http://bugs.python.org/issue6560> > ___ > -- ___ Python tracker <http://bugs.python.org/issue6560> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2698] Extension module build fails for MinGW: missing vcvarsall.bat
Bill Janssen added the comment: Actually, when using setup.py with MinGW, you just need to say the right thing: % python setup.py build --compiler=mingw32 install That removes the check for vcvarsall.bat. Bill On Mon, Jan 2, 2012 at 6:19 AM, Piotr Dobrogost wrote: > > Piotr Dobrogost added the comment: > > @Lehmann > > You have to have either Visual Studio 2008 or Visual C++ Express 2008 > installed. The folder where vcvarsall.bat file is being looked for is read > from the registry. It's either > HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\9.0\Setup\VC > (for Visual Studio) or > HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VCExpress\9.0\Setup\VC (for > Visual C++ Express). > > -- > nosy: +piotr.dobrogost > > ___ > Python tracker > <http://bugs.python.org/issue2698> > ___ -- ___ Python tracker <http://bugs.python.org/issue2698> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12765] test_packaging failure under Snow Leopard
Bill Janssen added the comment: I'm on vacation right now and can't get to it... Bill On Thu, Aug 18, 2011 at 12:22 PM, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > Bill is the owner of that buildbot. > > -- > nosy: +janssen > > ___ > Python tracker > <http://bugs.python.org/issue12765> > ___ > -- ___ Python tracker <http://bugs.python.org/issue12765> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6560] socket sendmsg(), recvmsg() methods
Bill Janssen added the comment: I'll take a look at this next week, when I'm more on-line again. Bill 2011/8/25 Charles-François Natali : > > Charles-François Natali added the comment: > >> The OS X buildbots show some failures: > > It seems to fail consistently on every OS X version. > I've had another look both at the code and the test, and couldn't find > anything wrong with it. > Since there are a number of known bugs pertaining to FD passing on OS X - > even on recent versions - I'd suggest to skip those tests on this platform. > As for sendto/sendmsg not being interrupted by the signal, I'd be curious to > see if running test_socket alone solves the problem (just to make sure no > other thread is running, which might receive the signal). > > -- > > ___ > Python tracker > <http://bugs.python.org/issue6560> > ___ > -- ___ Python tracker <http://bugs.python.org/issue6560> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8845] Expose sqlite3 connection inTransaction as read-only in_transaction attribute
Bill Janssen added the comment: PPC Tiger is using Python 2.7, so it's 3.6.11. Python 3.X also seems to be failing the sqlite tests on PPC Leopard. Is the required version # different between 3.1 and 3.x? -- ___ Python tracker <http://bugs.python.org/issue8845> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5117] os.path.relpath problem with root directory
Bill Janssen added the comment: Broke bunches of 2.7 buildbots. But why are we running test_ntpath on OS X, anyway? Shouldn't this be skipped everywhere except win32 platforms? -- nosy: +janssen ___ Python tracker <http://bugs.python.org/issue5117> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5117] os.path.relpath problem with root directory
Bill Janssen added the comment: Then we need to revert this patch and find one that works. -- resolution: fixed -> ___ Python tracker <http://bugs.python.org/issue5117> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2838] Verify callback for SSL
Bill Janssen <[EMAIL PROTECTED]> added the comment: On the client side, are you passing a ca_certs file with the self-signed certificate in it? If not, the library won't be able to validate the certificate enough to be able to see the data in it. But if you do that, you should be able to see the bits of the certificate. There's no point to seeing the bits of an unvalidated certificate, because they may be forged. So the library doesn't allow you to see the bits of an unvalidated certificate from the other side of the connection. -- assignee: -> janssen nosy: +janssen __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2838> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2838] Verify callback for SSL
Bill Janssen <[EMAIL PROTECTED]> added the comment: Yep, it looks like you're on the right track. I'll close this bug. Bill On Wed, May 14, 2008 at 12:51 PM, Ruben Kerkhof <[EMAIL PROTECTED]> wrote: > > Ruben Kerkhof <[EMAIL PROTECTED]> added the comment: > > Hi Bill, > > When I include the server certificate in ca_certs, verification > succeeds, and I can view the peer certificate dict with getpeercert(False) > > When I set ca_certs to none and ssl.CERT_NONE, I can still call > getpeercert(True) and call DER_cert_to_PEM_cert to get the same PEM > certificate. > > SSL is all new to me, so forgive me if I talk nonsense, but what I'm > trying to do is the following: > > I receive a key from Bob which is a digest of his servers certificate. > To make sure I'm really talking to Bob I need to decrypt his servers > signature with his public key and check the resulting digest against my > key. So I have to ignore failures like > X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT and > X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN, but detect things like > X509_V_ERR_CERT_SIGNATURE_FAILURE. > > The idea is based on what foolscap is doing with FURLS > (http://foolscap.lothar.com/trac) > > Am I making sense? > > __ > Tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue2838> > __ > Added file: http://bugs.python.org/file10323/unnamed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2838> __Yep, it looks like you're on the right track. I'll close this bug.BillOn Wed, May 14, 2008 at 12:51 PM, Ruben Kerkhof <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> wrote: Ruben Kerkhof <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> added the comment: Hi Bill, When I include the server certificate in ca_certs, verification succeeds, and I can view the peer certificate dict with getpeercert(False) When I set ca_certs to none and ssl.CERT_NONE, I can still call getpeercert(True) and call DER_cert_to_PEM_cert to get the same PEM certificate. SSL is all new to me, so forgive me if I talk nonsense, but what I'm trying to do is the following: I receive a key from Bob which is a digest of his servers certificate. To make sure I'm really talking to Bob I need to decrypt his servers signature with his public key and check the resulting digest against my key. So I have to ignore failures like X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT and X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN, but detect things like X509_V_ERR_CERT_SIGNATURE_FAILURE. The idea is based on what foolscap is doing with FURLS (http://foolscap.lothar.com/trac"; target="_blank">http://foolscap.lothar.com/trac) Am I making sense? __ Tracker <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> <http://bugs.python.org/issue2838"; target="_blank">http://bugs.python.org/issue2838> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2838] Verify callback for SSL
Changes by Bill Janssen <[EMAIL PROTECTED]>: -- resolution: -> works for me status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2838> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1251] ssl module doesn't support non-blocking handshakes
Bill Janssen <[EMAIL PROTECTED]> added the comment: Here's what's in the 3.0 docs: The parameter do_handshake_on_connect specifies whether to do the SSL handshake automatically after doing a socket.connect(), or whether the application program will call it explicitly, by invoking the SSLSocket.do_handshake()<http://docs.python.org/dev/3.0/library/ssl.html#ssl.SSLSocket.do_handshake>method. Calling SSLSocket.do_handshake()<http://docs.python.org/dev/3.0/library/ssl.html#ssl.SSLSocket.do_handshake>explicitly gives the program control over the blocking behavior of the socket I/O involved in the handshake. Look at test.test_ssl.testNonBlockingHandshake() in 3.0alpha or in the PyPI module. I'm still working on 2.6. Bill On Thu, May 15, 2008 at 3:56 PM, Jesús Cea Avión <[EMAIL PROTECTED]> wrote: > > Jesús Cea Avión <[EMAIL PROTECTED]> added the comment: > > I'm hitting this issue aswell. How is going?. > > I'm creating a socket with a, let say, 5 seconds timeout. The timeout > works fine before the "wrap_socket()", and after it. But the timeout > doesn't work WHILE in the "wrap_socket()" method call. > > What can I do?. > > If I need to call "do_handshake()" myself, working with > SSL_ERROR_WANT_READ/WRITE, I think this *needs* to be documented somewhere. > > That is, any difference between "normal" sockets and "ssl" sockets need > to be documented in docs. Explicitly. > > My opinion, of course :). > > __ > Tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue1251> > __ > Added file: http://bugs.python.org/file10337/unnamed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1251> __Here's what's in the 3.0 docs:The parameter do_handshake_on_connect specifies whether to do the SSL handshake automatically after doing a socket.connect(), or whether the application program will call it explicitly, by invoking the http://docs.python.org/dev/3.0/library/ssl.html#ssl.SSLSocket.do_handshake";>SSLSocket.do_handshake() method. Calling http://docs.python.org/dev/3.0/library/ssl.html#ssl.SSLSocket.do_handshake";>SSLSocket.do_handshake() explicitly gives the program control over the blocking behavior of the socket I/O involved in the handshake.Look at test.test_ssl.testNonBlockingHandshake() in 3.0alpha or in the PyPI module. I'm still working on 2.6.Bill On Thu, May 15, 2008 at 3:56 PM, Jesús Cea Avión <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> wrote: Jesús Cea Avión <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> added the comment: I'm hitting this issue aswell. How is going?. I'm creating a socket with a, let say, 5 seconds timeout. The timeout works fine before the "wrap_socket()", and after it. But the timeout doesn't work WHILE in the "wrap_socket()" method call. What can I do?. If I need to call "do_handshake()" myself, working with SSL_ERROR_WANT_READ/WRITE, I think this *needs* to be documented somewhere. That is, any difference between "normal" sockets and "ssl" sockets need to be documented in docs. Explicitly. My opinion, of course :). __ Tracker <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> <http://bugs.python.org/issue1251"; target="_blank">http://bugs.python.org/issue1251> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2936] ctypes.util.find_library() doesn't consult LD_LIBRARY_PATH
New submission from Bill Janssen <[EMAIL PROTECTED]>: The "find_library()" function in ctypes.util doesn't look in LD_LIBRARY_PATH on Solaris or Linux or most other UNIX variants that use that convention. This means that find_library() doesn't find libraries that dlopen() would, and makes development with ctypes much harder than it should be. -- components: Library (Lib) messages: 67170 nosy: janssen priority: normal severity: normal status: open title: ctypes.util.find_library() doesn't consult LD_LIBRARY_PATH type: behavior versions: Python 2.5, Python 2.6, Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2936> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2783] ctypes.util.find_library() doesn't find OS X .bundle or .so libraries
Bill Janssen <[EMAIL PROTECTED]> added the comment: I thought you might say that :-). No, I'm good with this resolution. If I provide a patch, it will be for the LD_LIBRARY_PATH problem. Though -- I think there's an interesting question about what the purpose of "find_library()" actually is, as opposed to what it's current implementation is. I disagree with Ronald's strict reading of the documentation. I think it should emulate the behavior of the dynamic linker, not the C compiler. That is, it should look for the libraries as "ld.so" (or its platform equivalent) would, because the purpose of finding them is to load them with CDLL. This behavior is different from what the compiler does. I also think find_library() should just be moved into the ctypes library, not dangling off by itself in the otherwise unused util sub-module. Bill On Wed, May 21, 2008 at 11:39 AM, Thomas Heller <[EMAIL PROTECTED]> wrote: > > Thomas Heller <[EMAIL PROTECTED]> added the comment: > > Thanks, Ronald. Sounds like this bug could be closed then. > > Bill, if you want a library search function with different semantics, > I suggest you open a feature request, describe the sematics that > should be used and (ideally) provide a patch. > > __ > Tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue2783> > __ > Added file: http://bugs.python.org/file10394/unnamed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2783> __I thought you might say that :-). No, I'm good with this resolution. If I provide a patch, it will be for the LD_LIBRARY_PATH problem.Though -- I think there's an interesting question about what the purpose of "find_library()" actually is, as opposed to what it's current implementation is. I disagree with Ronald's strict reading of the documentation. I think it should emulate the behavior of the dynamic linker, not the C compiler. That is, it should look for the libraries as "ld.so" (or its platform equivalent) would, because the purpose of finding them is to load them with CDLL. This behavior is different from what the compiler does. I also think find_library() should just be moved into the ctypes library, not dangling off by itself in the otherwise unused util sub-module.BillOn Wed, May 21, 2008 at 11:39 AM, Thomas Heller <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> wrote: Thomas Heller <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> added the comment: Thanks, Ronald. Sounds like this bug could be closed then. Bill, if you want a library search function with different semantics, I suggest you open a feature request, describe the sematics that should be used and (ideally) provide a patch. __ Tracker <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> <http://bugs.python.org/issue2783"; target="_blank">http://bugs.python.org/issue2783> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2936] ctypes.util.find_library() doesn't consult LD_LIBRARY_PATH
Bill Janssen <[EMAIL PROTECTED]> added the comment: You could do that, I can see how that would be useful, but I think it might be less confusing to just use the platform's way of doing that. For instance, on OS X, you can set DYLD_LIBRARY_PATH environment variable to put directories in front of the normal search path, and DYLD_FALLBACK_LIBRARY_PATH to put directories in back of the normal search path. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2936> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2936] ctypes.util.find_library() doesn't consult LD_LIBRARY_PATH
Bill Janssen <[EMAIL PROTECTED]> added the comment:
The question is, which linker? I think it should be ld.so, which links "on
demand", and does pay attention to LD_LIBRARY_PATH. I'm not sure what the
point of find_library() is, otherwise.
Bill
On Thu, May 29, 2008 at 11:24 AM, Thomas Heller <[EMAIL PROTECTED]>
wrote:
>
> Thomas Heller <[EMAIL PROTECTED]> added the comment:
>
> To be honest, I do not understand this request and the discussion.
> ctypes.util.find_library(), as dcumented, is supposed to simulate what
> the linker does: find the name of a shared library. For example,
> it returns 'libc.so.6' when called as ctypes.util.find_library('c').
> AFAIK (and I don't know very much about posix shared libs or linkers)
> the linker does not pay attention to (DY)LD_LIBRARY_PATH env var.
>
> dlopen(shared-lib-name) does use this env vars, but this behaviour is
> already built into dlopen.
>
> --
> assignee: -> theller
> nosy: +theller
>
> ___
> Python tracker <[EMAIL PROTECTED]>
> <http://bugs.python.org/issue2936>
> ___
>
Added file: http://bugs.python.org/file10476/unnamed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2936>
___The question is, which linker? I think it should be ld.so, which links
"on demand", and does pay attention to LD_LIBRARY_PATH. I'm
not sure what the point of find_library() is, otherwise.Bill
On Thu, May 29, 2008 at 11:24 AM, Thomas Heller <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> wrote:
Thomas Heller <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]>
added the comment:
To be honest, I do not understand this request and the discussion.
ctypes.util.find_library(), as dcumented, is supposed to simulate what
the linker does: find the name of a shared library. For example,
it returns 'libc.so.6' when called as
ctypes.util.find_library('c').
AFAIK (and I don't know very much about posix shared libs or linkers)
the linker does not pay attention to (DY)LD_LIBRARY_PATH env var.
dlopen(shared-lib-name) does use this env vars, but this behaviour is
already built into dlopen.
--
assignee: -> theller
nosy: +theller
___
Python tracker <mailto:[EMAIL PROTECTED]">[EMAIL
PROTECTED]>
<http://bugs.python.org/issue2936";
target="_blank">http://bugs.python.org/issue2936>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2936] ctypes.util.find_library() doesn't consult LD_LIBRARY_PATH
Bill Janssen <[EMAIL PROTECTED]> added the comment: Yes, I've read that explanation, but I still don't see what the point of find_library() is. Are you trying to resolve a possibly ambiguous reference to a shared library to the one which is used by the Python interpreter? If that's the case (and that's what the code seems to do), how about calling it "find_library_used_by_python", and have another function, perhaps called "find_library", which, given a partial name like "foo", searches the LD_LIBRARY_PATH (or, on Darwin, the DYLD_LIBRARY_PATH), if set, then the standard system locations, the, on Darwin, the DYLD_FALLBACK_LIBRARY_PATH, to find a library called "libfoo.so.N" (or, on Darwin, "libfoo.N.dylib")? That would be very useful. Right now, I don't see the use case for find_library(). Bill On Fri, May 30, 2008 at 1:58 PM, Thomas Heller <[EMAIL PROTECTED]> wrote: > > Thomas Heller <[EMAIL PROTECTED]> added the comment: > > > The question is, which linker? I think it should be ld.so, which links > "on > > demand", and does pay attention to LD_LIBRARY_PATH. I'm not sure what > the > > point of find_library() is, otherwise. > > The best explanation is in the python docs: > http://docs.python.org/lib/ctypes-finding-shared-libraries.html > > ___ > Python tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue2936> > ___ > Added file: http://bugs.python.org/file10487/unnamed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2936> ___Yes, I've read that explanation, but I still don't see what the point of find_library() is. Are you trying to resolve a possibly ambiguous reference to a shared library to the one which is used by the Python interpreter? If that's the case (and that's what the code seems to do), how about calling it "find_library_used_by_python", and have another function, perhaps called "find_library", which, given a partial name like "foo", searches the LD_LIBRARY_PATH (or, on Darwin, the DYLD_LIBRARY_PATH), if set, then the standard system locations, the, on Darwin, the DYLD_FALLBACK_LIBRARY_PATH, to find a library called "libfoo.so.N" (or, on Darwin, "libfoo.N.dylib")? That would be very useful. Right now, I don't see the use case for find_library(). BillOn Fri, May 30, 2008 at 1:58 PM, Thomas Heller <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> wrote: Thomas Heller <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> added the comment: > The question is, which linker? I think it should be ld.so, which links "on > demand", and does pay attention to LD_LIBRARY_PATH. I'm not sure what the > point of find_library() is, otherwise. The best explanation is in the python docs: http://docs.python.org/lib/ctypes-finding-shared-libraries.html"; target="_blank">http://docs.python.org/lib/ctypes-finding-shared-libraries.html ___ Python tracker <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> <http://bugs.python.org/issue2936"; target="_blank">http://bugs.python.org/issue2936> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2936] ctypes.util.find_library() doesn't consult LD_LIBRARY_PATH
Bill Janssen <[EMAIL PROTECTED]> added the comment:
OK, I went back and read the code. What I should be using is
"ctypes.cdll.LoadLibrary("libgoodstuff.1.dylib")". Thanks -- I think you
can close this issue.
Bill
On Fri, May 30, 2008 at 1:58 PM, Thomas Heller <[EMAIL PROTECTED]>
wrote:
>
> Thomas Heller <[EMAIL PROTECTED]> added the comment:
>
> > The question is, which linker? I think it should be ld.so, which links
> "on
> > demand", and does pay attention to LD_LIBRARY_PATH. I'm not sure what
> the
> > point of find_library() is, otherwise.
>
> The best explanation is in the python docs:
> http://docs.python.org/lib/ctypes-finding-shared-libraries.html
>
> ___
> Python tracker <[EMAIL PROTECTED]>
> <http://bugs.python.org/issue2936>
> ___
>
Added file: http://bugs.python.org/file10489/unnamed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2936>
___OK, I went back and read the code. What I should be using is
"ctypes.cdll.LoadLibrary("libgoodstuff.1.dylib")".
Thanks -- I think you can close this issue.Bill
On Fri, May 30, 2008 at 1:58 PM, Thomas Heller <mailto:[EMAIL
PROTECTED]">[EMAIL PROTECTED]> wrote:
Thomas Heller <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]>
added the comment:
> The question is, which linker? I think it
should be ld.so, which links "on
> demand", and does pay attention to LD_LIBRARY_PATH. I'm not
sure what the
> point of find_library() is, otherwise.
The best explanation is in the python docs:
http://docs.python.org/lib/ctypes-finding-shared-libraries.html";
target="_blank">http://docs.python.org/lib/ctypes-finding-shared-libraries.html
___
Python tracker <mailto:[EMAIL PROTECTED]">[EMAIL
PROTECTED]>
<http://bugs.python.org/issue2936";
target="_blank">http://bugs.python.org/issue2936>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3075] make minidom.toxml() encoding argument useful
New submission from Bill Janssen <[EMAIL PROTECTED]>: Right now, the encoding argument added to xml.dom.minidom.DOMObject.toxml() in Python 2.3 seems fairly useless. It has to be UTF-8. But a one-line change to the implementation of toprettyxml would make it useful; instead of the encoding error method being "strict", make it "xmlcharrefreplace". So change writer = codecs.lookup(encoding)[3](writer) to writer = codecs.lookup(encoding)[3](writer, "xmlcharrefreplace") -- components: Library (Lib) keywords: easy messages: 67909 nosy: janssen priority: normal severity: normal status: open title: make minidom.toxml() encoding argument useful versions: Python 2.6, Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3075> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3075] make minidom.toxml() encoding argument useful
Bill Janssen <[EMAIL PROTECTED]> added the comment: The method "toxml" is actually on xml.dom.minidom.Node. -- type: -> feature request ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3075> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3212] ssl module - should test for a wrong cert
Bill Janssen <[EMAIL PROTECTED]> added the comment: OK, good idea. I'll put it in. Bill On Thu, Jun 26, 2008 at 11:34 AM, Jonas Wagner <[EMAIL PROTECTED]> wrote: > > New submission from Jonas Wagner <[EMAIL PROTECTED]>: > > Currently test_ssl.py only tests for empty or broken certificates. One > can break certificate validation in _ssl.c and they still pass. > > The following patch should fix this. > > - Jonas > > -- > components: Tests > files: add_wrong_cert_test.diff > keywords: patch > messages: 68797 > nosy: janssen, jonas.wagner > severity: normal > status: open > title: ssl module - should test for a wrong cert > type: feature request > versions: Python 2.6 > Added file: http://bugs.python.org/file10745/add_wrong_cert_test.diff > > ___ > Python tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue3212> > ___ > Added file: http://bugs.python.org/file10747/unnamed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3212> ___OK, good idea. I'll put it in.BillOn Thu, Jun 26, 2008 at 11:34 AM, Jonas Wagner <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> wrote: New submission from Jonas Wagner <[EMAIL PROTECTED]>: Currently test_ssl.py only tests for empty or broken certificates. One can break certificate validation in _ssl.c and they still pass. The following patch should fix this. - Jonas -- components: Tests files: add_wrong_cert_test.diff keywords: patch messages: 68797 nosy: janssen, jonas.wagner severity: normal status: open title: ssl module - should test for a wrong cert type: feature request versions: Python 2.6 Added file: http://bugs.python.org/file10745/add_wrong_cert_test.diff"; target="_blank">http://bugs.python.org/file10745/add_wrong_cert_test.diff ___ Python tracker <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> <http://bugs.python.org/issue3212"; target="_blank">http://bugs.python.org/issue3212> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3212] ssl module - should test for a wrong cert
Bill Janssen <[EMAIL PROTECTED]> added the comment: I've added this into my patch. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3212> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3162] ssl.SSLSocket implements methods that are overriden by socket.socket.__init__ and methods with incorrect names.
Bill Janssen <[EMAIL PROTECTED]> added the comment: Thanks for pointing this out. I've got a patch for the overrides and the misnamings already. We don't have implementations for recvfrom_into, or recv_into. If you'd care to create a patch for that, it would help. -- assignee: -> janssen nosy: +janssen resolution: -> accepted ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3162> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
