[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 Dob

[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

[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 consistentl

[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. > >

[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/iss

[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.py

[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

[issue9455] platform test borked in 2.7 branch on Power PC

Bill Janssen added the comment: So the problem is in the _mac_ver_xml() routine in Lib/platform.py, which says: machine = os.uname()[4] if machine == 'ppc': # for compatibility with the gestalt based code machine = 'PowerPC' and perhaps shou

[issue9455] platform test borked in 2.7 branch on Power PC

Bill Janssen added the comment: This is on a PowerPC machine running Leopard: >>> os.uname()[4] 'Power Macintosh' >>> -- ___ Python tracker <h

[issue9455] platform test borked in 2.7 branch on Power PC

New submission from Bill Janssen : Looks like some test borked the 2.7 tests on the buildbots. Here's the offending test: test test_platform failed -- Traceback (most recent call last): File "/Users/buildbot/buildarea/2.7.parc-leopard-1/build/Lib/test/test_platform.py"

[issue8447] buildbot: test_httpservers failure (No module named operator)

Bill Janssen added the comment: Failing on my PPC Tiger OS X buildbot, with 2.6, too. -- nosy: +janssen versions: +Python 2.6 ___ Python tracker <http://bugs.python.org/issue8

[issue8621] uuid.uuid4() generates non-unique values on OSX

Bill Janssen added the comment: Stefan, I tried your suggestion of starting threading. Test still succeeds on my 10.5.8 system when test_uuid is run separately. Ronald, your fix works on my 10.5.8 system. Why not check it in, and let's see if the buildbots turn green

[issue9048] no OS X buildbots in the stable list

Bill Janssen added the comment: Bit of a chicken/egg issue here. Since we haven't had OS X buildbots for very long, and the ones we do have represent odd configurations, I think it's premature to say that "the port *doesn't* pass the test suite on a regular manner&quo

[issue8621] uuid.uuid4() generates non-unique values on OSX

Bill Janssen added the comment: This is on an Intel machine running OS X 10.5.8. I downloaded and built 2.7rc2 from source with "./configure ; make". I then ran the tests with "make test". test_uuid fails with this output: test test_uuid failed -- Traceback (m

[issue9052] 2.7rc2 fails test_urllib_localnet tests on OS X

New submission from Bill Janssen : % ./python.exe -Wd -3 -E -tt ./Lib/test/regrtest.py -v test_urllib2_localnet == CPython 2.7rc2 (r27rc2:82137, Jun 21 2010, 12:50:22) [GCC 4.0.1 (Apple Inc. build 5493)] == Darwin-9.8.0-i386-32bit little-endian == /private/tmp/Python-2.7rc2/build

[issue9048] no OS X buildbots in the stable list

Changes by Bill Janssen : -- components: +None keywords: +buildbot versions: -Python 2.7 ___ Python tracker <http://bugs.python.org/issue9048> ___ ___ Python-bug

[issue9048] no OS X buildbots in the stable list

New submission from Bill Janssen : Considering the number of OS X machines running Python programs, it would be good idea to get this platform into the "stable" list of buildbots so that releases are checked against it. -- messages: 108302 nosy: janssen priority: norma

[issue8446] buildbot: DeprecationWarning not raised for icglue (test_py3kwarn.TestStdlibRemovals)

Bill Janssen added the comment: Not sure I understand this patch. Either the icglue module is removed in python 3, in which case it should raise the deprecation warning, or it is not, in which case it should be removed from the list of modules checked in test_py3kwarn. Shouldn't the

[issue8716] test_tk fails on OS X if run from buildbot slave daemon -- crashes Python

Bill Janssen added the comment: It's fairly easy to create a restricted process tree for testing. ssh into a Mac which has no one logged into the console, from another machine, and use that connection to launch an xterm or Xemacs window to the other machine. Then log out of the ssh se

[issue8716] test_tk fails on OS X if run from buildbot slave daemon -- crashes Python

Bill Janssen added the comment: [More info from Ronald Oussoren] This is a bug in Tk: >>> root = Tkinter.Tk() Thu May 13 20:45:13 Rivendell.local python[84887] : kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged. _RegisterApplication(),

[issue8716] test_tk fails on OS X if run from buildbot slave daemon -- crashes Python

New submission from Bill Janssen : test_tk fails on OS X if test is run from a daemon process without the privilege to access the window server, say a buildbot slave without anyone logged in to the console. The Tk support needs to check whether it has access rights to the window server

[issue8552] msilib can't create large CAB files

Bill Janssen added the comment: Ah, found the size problem -- I was measuring something in 512 blocks not 1KB blocks. Never mind. -- ___ Python tracker <http://bugs.python.org/issue8

[issue8552] msilib can't create large CAB files

Bill Janssen added the comment: Another bit of info. It's the frequent commits that seem to fix the problem; when I comment those out of the __del__ method, it fails as before. I also notice that the finished installer is about twice the size of the two data files in it (the CAB fil

[issue8552] msilib can't create large CAB files

Bill Janssen added the comment: I've now been able to build my installer. I applied Travis Oliphant's patch from http://bugs.python.org/issue2399 to Lib/msilib/__init__.py, then added a __del__ method to the Directory class: def __del__(self): if self._numfiles_wo_

[issue8552] msilib can't create large CAB files

Changes by Bill Janssen : Removed file: http://bugs.python.org/file17118/unnamed ___ Python tracker <http://bugs.python.org/issue8552> ___ ___ Python-bugs-list mailin

[issue8552] msilib can't create large CAB files

Bill Janssen added the comment: Yes, I've tried that. No joy. Right now I'm trying an approach which packages each top-level directory as a separate cab. What I'm finding is that if I get up around 4200 files, it breaks, regardless of the file sizes. Out of curiosity, how ma

[issue8554] suspicious comment in msilib.py/__init__.py

New submission from Bill Janssen : Take a look at the first line of make_id(). What does that comment mean? Is the wrong line commented out? def make_id(str, add_num=True): #str = str.replace(".", "_") # colons are allowed -- components: Library (Lib), Wind

[issue8552] msilib can't create large CAB files

Bill Janssen added the comment: So, I subclassed msilib.CAB, and re-wrote commit() so that the CAB file is created in a different process, a la Tools/msi/msilib.py. Still have the same problem, though. So now I'm thinking it's not a memory problem, but I'm wondering if th

[issue8552] msilib can't create large CAB files

Bill Janssen added the comment: Ummm, just in case the packager wanted to. In my case, I was putting the files which were registered as part of the installation in one CAB file, and another set of temporary files which were used by some of the installation scripts, but not part of the

[issue8552] msilib can't create large CAB files

New submission from Bill Janssen : I'm trying to create a CAB file containing about 69MB of data, in 4555 files. msilib fails in CAB.commit(): $ python build-msi-installer.py /c/UpLib/1.7.9 ~/uplib 1.7.9 ./uplib-1.7.9.msi c:\Documents and Settings\wjanssen\uplib\win32\uplib-1.7.

[issue3216] Scarce msilib documentation

Bill Janssen added the comment: Here's another one: class Directory shows an extra arg, "component", which isn't in the code. -- nosy: +janssen ___ Python tracker <http://bu

[issue8526] msilib doesn't support multiple CAB instances in same installer

Bill Janssen added the comment: I'm certainly using the API provided by msilib, but perhaps I'm using it badly. Which API did you have in mind? I'm using msilib directly, not through bdist_msi. This seems like an artificial limitation to put on the Python library; the st

[issue8526] msilib doesn't support multiple CAB instances in same installer

New submission from Bill Janssen : Working with Python 2.6.5, I find I cannot put multiple CABs in the same installer. This is due to this statement in msilib.CAB.commit(): add_data(db, "Media", [(1, self.index, None, "#"+self.name, None, None)])

[issue1128] msilib.Directory.make_short only handles file names with a single dot in them

Bill Janssen added the comment: Here's how Microsoft does it: http://support.microsoft.com/kb/142982/en-us -- ___ Python tracker <http://bugs.python.org/i

[issue7639] bdist_msi fails on files with long names

Bill Janssen added the comment: This looks a lot like bug 1128, too. I think the patch there would also fix this one. -- nosy: +janssen ___ Python tracker <http://bugs.python.org/issue7

[issue1128] msilib.Directory.make_short only handles file names with a single dot in them

Bill Janssen added the comment: So what happens if the original file name is something like "foo~1.txt"? Couldn't there be a name collision? -- nosy: +janssen ___ Python tracker <http://bugs.py

[issue8222] enabling SSL_MODE_AUTO_RETRY on SSL sockets

Bill Janssen added the comment: Looks like a good idea. -- ___ Python tracker <http://bugs.python.org/issue8222> ___ ___ Python-bugs-list mailing list Unsub

[issue2445] Use The CygwinCCompiler Under Cygwin

Bill Janssen added the comment: Shouldn't the import library name end with .lib? I've run up against this building PyLucene with MinGW. There seems to be code to figure this out already in CygwinCCompiler, but it's commented out (and arguably incomplete). --

[issue2698] Extension module build fails for MinGW: missing vcvarsall.bat

Bill Janssen added the comment: My bad. Adding --compiler=mingw32 eliminates this error. -- resolution: -> rejected status: open -> closed ___ Python tracker <http://bugs.python.org/

[issue2698] Extension module build fails for MinGW: missing vcvarsall.bat

Bill Janssen added the comment: Re-opening. -- keywords: +26backport priority: high -> normal resolution: invalid -> status: closed -> open ___ Python tracker <http://bugs.python.o

[issue2698] Extension module build fails for MinGW: missing vcvarsall.bat

Bill Janssen added the comment: I'm seeing this on Python 2.6.4 on Windows XP with the latest MinGW/msys. -- nosy: +janssen ___ Python tracker <http://bugs.python.org/i

[issue8108] test_ftplib fails with OpenSSL 0.9.8m

Bill Janssen added the comment: >> Depends on what we want. It just suppresses information that's now >> available. What we'd really like is for the caller to recognize that >> close() can fail, and should be re-tried if it does. That requires >> that we s

[issue8108] test_ftplib fails with OpenSSL 0.9.8m

Bill Janssen added the comment: > Maybe because only the FTP test uses an SSL socket in non blocking mode. No, the SSL unit tests also do this. I think Giampaolo is right, what we're seeing is bad error handling in the FTP t

[issue8108] test_ftplib fails with OpenSSL 0.9.8m

Bill Janssen added the comment: > AFAICT, his proposed "quick fix" snippet should be good enough for us. Depends on what we want. It just suppresses information that's now available. What we'd really like is for the caller to recognize that close() can fail, and s

[issue8108] test_ftplib fails with OpenSSL 0.9.8m

Bill Janssen added the comment: And it would be interesting to know why all the SSL module tests don't fail in the same way. -- ___ Python tracker <http://bugs.python.org/i

[issue8108] test_ftplib fails with OpenSSL 0.9.8m

Bill Janssen added the comment: I think Giampaolo is right about this not being an ssl.py issue. Could the exception handling in ftp.py perhaps also be made more sophisticated? I'd really love to understand what the state of the TCP connection is here. I'm presuming that it&#x

[issue8108] test_ftplib fails with OpenSSL 0.9.8m

Bill Janssen added the comment: Looking at this further, what we're seeing is the trace of an ineffective attempt to handle an exception presumably raised from the FTP code. Can we see that exception? What's the actual state of the TCP connection at

[issue8108] test_ftplib fails with OpenSSL 0.9.8m

Bill Janssen added the comment: What's happening is that the new state returns from SSL_shutdown() are saying, "the shutdown you asked for didn't happen this time, but call me again when you get a chance. And here is a hint about why it didn't happen, so that if you are

[issue8108] test_ftplib fails with OpenSSL 0.9.8m

Bill Janssen added the comment: Victor, I'll take a look. -- ___ Python tracker <http://bugs.python.org/issue8108> ___ ___ Python-bugs-list mailing list

[issue7672] _ssl module causes segfault

Bill Janssen added the comment: Martin, I'm thinking that the module object has a __del__ method, and we could un-register the callbacks there. But I don't know if that method would ever get called. How does the act of "unloading a library" interact with the initialize

[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets

Bill Janssen added the comment: On Tue, Sep 29, 2009 at 12:47 PM, Giampaolo Rodola' wrote: > > Giampaolo Rodola' added the comment: > > Uhm... I'm sorry but actually I'm not sure about this patch anymore. > Now that I look at ssl.py again I'm noticing t

[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets

Bill Janssen added the comment: I wonder if there is any way to test this, aside from the tests that are already in the test suite? The bug here is that the code effectively does a blocking read on a non-blocking socket, and we can't tell the difference. The fact that this patch passe

[issue4033] python search path - .pth recursion

Bill Janssen added the comment: Looks like 1431 was closed by removing a line from the documentation, so it's not surprising that it's not clear. -- nosy: +janssen ___ Python tracker <http://bugs.python.

[issue6587] interrupts during long writes cause connection corruption with SSL module

New submission from Bill Janssen : The behavior when a write or send is interrupted is suboptimal. If the write buffer moves before a retry is attempted in response to SSL_ERROR_WANT_OUTPUT, OpenSSL rejects the retry attempt. See http://www.mail-archive.com/openssl-us...@openssl.org/msg07806

[issue4848] MacPython build script uses Carbon and MacOS modules slated for removal

Bill Janssen added the comment: Looks good. The contrast is stark. ___ Python tracker <http://bugs.python.org/issue4848> ___ ___ Python-bugs-list mailing list Unsub

[issue4471] IMAP4 missing support for starttls

Bill Janssen added the comment: I brought this up on pydotorg, and Barry suggests that someone put together a Twisted environment which could be downloaded and run locally on the test machine. It would provide IMAP and POP servers, perhaps NNTP and others as well. Now, all we need is someone

[issue1978] Python(2.5.1) will be crashed when i use _ssl module in multi-threads environment in linux.

Bill Janssen added the comment: Yes, the reason is that the supplied patch doesn't provide enough test cases. This is a big patch; 2.5.x is a bug-fix release; a newer version of the SSL code is available from PyPI as a work-around; I don't have time right now to write more tests my

[issue4471] IMAP4 missing support for starttls

Bill Janssen added the comment: Why can't we use python.org for tests? Do we need IMAP/POP servers running? Let's send some mail to pydotorg to get that set up. ___ Python tracker <http://bugs.python.

[issue2437] Distutils runtime_library_dirs broken on Windows

Bill Janssen added the comment: Tarek writes: > Laurent, right. but we need to figure out how to get the CC name in > MinGW/Cygwin environment. > I am not familiar with them. Since this bug is specifically about that environment, shouldn't it be handled by someone who is fami

[issue2437] Distutils runtime_library_dirs broken on Windows

Bill Janssen added the comment: No, Tarek, I don't have a MinGW machine right now. But it should be easy to reproduce; just invoke that call I originally reported. The distutils code is just making assumptions that it shouldn't be making.

[issue5238] ssl makefile never closes socket

Bill Janssen added the comment: I'd recommend running the whole suite of tests here. The issue is mainly with httplib, as I recall it, which "closes" the socket before it finishes reading from it. ___ Python tracker <http://bugs.py

[issue4471] IMAP4 missing support for starttls

Bill Janssen added the comment: Lorenzo, do we have test cases for this? I think you should try to add some test cases. We may need to set up some test mail servers on python.org to accommodate such tests. -- nosy: +janssen ___ Python tracker

[issue1251] ssl module doesn't support non-blocking handshakes

Bill Janssen added the comment: Well, maybe he found something -- never reported back. But it was a few months ago... I'm in no hurry to close it, though. ___ Python tracker <http://bugs.python.org/i

[issue4870] ssl module is missing SSL_OP_NO_SSLv2

Bill Janssen added the comment: Actually, that's not quite true. Specifying TLSv1 or SSLv3 on the server side will disable SSLv2. However, there's currently no way to specify SSLv3 *or* TLSv1 *but not* SSLv2. This looks easy to fix; I'll add another entry to the list of pr

[issue4848] MacPython build script uses Carbon and MacOS modules slated for removal

New submission from Bill Janssen : The build script for a Mac OS installer, in Mac/BuildScript/build-installer.py, currently requires OS 10.4 and Python 2.3. At some point it will have to be ported to a newer version of Python (and Mac OS). It uses a number of modules which are slated for

[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets

Bill Janssen <[EMAIL PROTECTED]> added the comment: Unrelated? OK, but in fact I fixed this in 3.0 by providing a different internal API to _ssl.c. But you're right, that's an optimization. ___ Python tracker <[EMAIL PROTECTED]> &

[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets

Bill Janssen <[EMAIL PROTECTED]> added the comment: Thanks for the patch. It looks pretty good to me, but I can't help thinking that there must be a better way of handling the recv() case; I don't like copying that buffer several times (from the SSL code to Python, from the Pyth

[issue4171] SSL handshake fails after TCP connection in getpeername()

Changes by Bill Janssen <[EMAIL PROTECTED]>: -- assignee: -> janssen ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4171> ___ ___

[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets

Bill Janssen <[EMAIL PROTECTED]> added the comment: I agree, too. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3890> ___ ___ Python-bugs

[issue1210] imaplib does not run under Python 3

Bill Janssen <[EMAIL PROTECTED]> added the comment: Maybe the first thing to do is to expand the Lib/test/test_imaplib.py file, which right now is pretty darn minimal. We really need an IMAP server somewhere to test against, with a standard library of varied messages. Perhaps Python.

[issue1210] imaplib does not run under Python 3

Bill Janssen <[EMAIL PROTECTED]> added the comment: Victor, what kind of content have you tried this with? For instance, have you passed unencoded (Content-Transfer-Encoding: binary) binary data through it, by mailing a JPEG, for instance? These things are strings really only

[issue2276] distutils out-of-date for runtime_library_dirs flag on OS X

Bill Janssen <[EMAIL PROTECTED]> added the comment: Yes, we were looking at using this for linking PyLucene's JCC extension. I believe we came up with a different way of doing it. It would still be useful to have distutils.unixccompiler.runtime_library_dir_option() updated to und

[issue3991] urllib.request.urlopen does not handle non-ASCII characters

Bill Janssen <[EMAIL PROTECTED]> added the comment: I'm not concerned about any example inputs. I was just trying to explain why this isn't a bug. On the other hand, the IRI spec (RFC 3897) is another thing we might try to implement for Python. -- type: -&

[issue3991] urllib.request.urlopen does not handle non-ASCII characters

Bill Janssen <[EMAIL PROTECTED]> added the comment: It's not immediately clear to me how an auto-quote function can be written; as you say (and as the URI spec points out), you have to take a URL apart before quoting it, and you can't parse an invalid URL, which is what the in

[issue3991] urllib.request.urlopen does not handle non-ASCII characters

Bill Janssen <[EMAIL PROTECTED]> added the comment: As I read RFC 2396, 1.5: "A URI is a sequence of characters from a very limited set, i.e. the letters of the basic Latin alphabet, digits, and a few special characters." 2.4: "Data must be escaped if it does not

[issue3910] 2.6 regression in socket.ssl method

Bill Janssen <[EMAIL PROTECTED]> added the comment: OK, I found the fix. -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs

[issue3910] 2.6 regression in socket.ssl method

Bill Janssen <[EMAIL PROTECTED]> added the comment: Maybe not. test_ssl hangs when I run it "-u all -v". It's hanging on testSimpleSSLWrap. This is on OS X 10.5.5. ___ Python tracker <[EMAIL PROTECTED]> <ht

[issue3910] 2.6 regression in socket.ssl method

Bill Janssen <[EMAIL PROTECTED]> added the comment: Will do. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3910> ___ ___ Python-bugs

[issue3899] test_ssl.py doesn't properly test ssl integration with asyncore

Bill Janssen <[EMAIL PROTECTED]> added the comment: Sure, no argument. I was just making clear what was going on. Bill On Thu, Sep 18, 2008 at 7:33 PM, Josiah Carlson <[EMAIL PROTECTED]>wrote: > > Josiah Carlson <[EMAIL PROTECTED]> added the comment: > > Being a

[issue3910] 2.6 regression in socket.ssl method

Bill Janssen <[EMAIL PROTECTED]> added the comment: Looks OK to me. I think this is a back-port problem from 3.0. I'll put it in if no one objects. -- assignee: -> janssen ___ Python tracker <[EMAIL PROTECTED]> <http://bu

[issue3899] test_ssl.py doesn't properly test ssl integration with asyncore

Bill Janssen <[EMAIL PROTECTED]> added the comment: The server wasn't meant to be non-blocking. The non-blocking test is performed when the client (which is non-blocking) connects to it. ___ Python tracker <[EMAIL PROTECTED]> <ht

[issue2574] Add RFC 3768 SSM Multicast support to "socket"

Bill Janssen <[EMAIL PROTECTED]> added the comment: On Wed, Sep 17, 2008 at 10:45 AM, bms <[EMAIL PROTECTED]> wrote: > > Exercising the API fully requires an SSM capable multicast LAN. > Let's hope the PARC network is still up-to-date. It was when we were developing

[issue2574] Add RFC 3768 SSM Multicast support to "socket"

Bill Janssen <[EMAIL PROTECTED]> added the comment: I tried applying this patch to a clean SVN checkout of the 2.6 trunk on an OS X Leopard machine and it works (except for the part which patches configure.in). I then built the source tree and ran the test_socket test, which also worke

[issue1589] New SSL module doesn't seem to verify hostname against commonName in certificate

Bill Janssen <[EMAIL PROTECTED]> added the comment: I think that, where it's appropriate, you can do that. Just don't put it in the SSL module. Bill On Wed, Sep 10, 2008 at 11:24 PM, Heikki Toivonen <[EMAIL PROTECTED]>wrote: > > Heikki Toivonen <[EMAIL PROTEC

[issue3823] ssl.wrap_socket() is incompatible with servers that drop privileges, due to keyfile requirement

Bill Janssen <[EMAIL PROTECTED]> added the comment: Sure -- but the point of the SSL module was to do something small and compatible with the existing socket.ssl module; I really don't want to get into a full-fledged Python interface to OpenSSL. Perhaps incremental progress

[issue3823] ssl.wrap_socket() is incompatible with servers that drop privileges, due to keyfile requirement

Bill Janssen <[EMAIL PROTECTED]> added the comment: Thanks, Simon. I remember digging through all this last year, and finally deciding to keep things simple and use the strategy the current codebase uses. It almost sounds like we'd need to create Key and Certificate objects in the

[issue1589] New SSL module doesn't seem to verify hostname against commonName in certificate

Bill Janssen <[EMAIL PROTECTED]> added the comment: Sorry to be so brief there -- I was off on vacation. Verifying hostnames is a prescription that someone (well, OK, Eric Rescorla, who knows what he's talking about) put in the https IETF RFC (which, by the way, is only an inform

[issue3823] ssl.wrap_socket() is incompatible with servers that drop privileges, due to keyfile requirement

Changes by Bill Janssen <[EMAIL PROTECTED]>: -- resolution: -> accepted ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3823> ___ __

[issue3805] sslobj.read py3k takes odd arguments

Bill Janssen <[EMAIL PROTECTED]> added the comment: But I should say... Greg, I do appreciate the review and the comments. I was waiting for the bytes work in 3K to settle down before looking at that code again. When I do, I'll take your commen

[issue3805] sslobj.read py3k takes odd arguments

Changes by Bill Janssen <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11446/unnamed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue3805] sslobj.read py3k takes odd arguments

Bill Janssen <[EMAIL PROTECTED]> added the comment: Please, guys, let's not deep-end on this. It's an admittedly eccentric but working and purely internal interface. There are actual release-blockers that need to be addressed. On Tue, Sep 9, 2008 at 4:14 AM, Amaury Forge

[issue3805] sslobj.read py3k takes odd arguments

Changes by Bill Janssen <[EMAIL PROTECTED]>: -- priority: high -> low ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3805> ___ ___

[issue3805] sslobj.read py3k takes odd arguments

Bill Janssen <[EMAIL PROTECTED]> added the comment: There was a reason to do it that way. Now if I can only remember what it was... ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue3162] ssl.SSLSocket implements methods that are overriden by socket.socket.__init__ and methods with incorrect names.

Bill Janssen <[EMAIL PROTECTED]> added the comment: And for the 3K branch. Thanks! -- resolution: accepted -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs

[issue3162] ssl.SSLSocket implements methods that are overriden by socket.socket.__init__ and methods with incorrect names.

Bill Janssen <[EMAIL PROTECTED]> added the comment: I've applied Simon's patch to the 2.6 trunk. ___ Python tracker <[EMAIL PROTECTED]> <http://

[issue3162] ssl.SSLSocket implements methods that are overriden by socket.socket.__init__ and methods with incorrect names.

Bill Janssen <[EMAIL PROTECTED]> added the comment: Re: nomenclature I think this is partly a design bug on my part, supporting the old pre-2.6 "read" and "write" methods on the SSL context. Users should really call "makefile" to get something they can &quo

[issue1291446] SSLObject breaks read semantics

Bill Janssen <[EMAIL PROTECTED]> added the comment: Ah, sorry. I was looking at the 2.6 documentation, not the 2.5 documentation. In 2.6 (which is what the new SSL code is for), documentation of socket.ssl has been removed entirely, along with the text that you cite, although the functio

[issue3162] ssl.SSLSocket implements methods that are overriden by socket.socket.__init__ and methods with incorrect names.

Bill Janssen <[EMAIL PROTECTED]> added the comment: Simon, thanks, this patch looks good to me (2.6 only, right?). I'll try it out and report back. If it looks good, I'll commit it. ___ Python tracker <[EMAIL PROTECTED]> <http://

[issue1291446] SSLObject breaks read semantics

Bill Janssen <[EMAIL PROTECTED]> added the comment: The way I read the documentation, file.read() (and that's what we're talking about) is still not guaranteed to read all the bytes of the file. But, you're right, that is the accepted semantics. So the documentati

[issue1210] imaplib does not run under Python 3

Bill Janssen <[EMAIL PROTECTED]> added the comment: Take a look at the thread here: http://mailman2.u.washington.edu/mailman/htdig/imap-protocol/2008-February/000811.html I think the summary is, arbitrary bytes may occur in some places, but they're likely to be UTF-8. Otherwise,

  1   2   3   4   >