Changes by Bill Janssen:
--
nosy: +janssen
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1018>
__
___
Python-bugs-list mailing list
Unsubs
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
Bill Janssen added the comment:
Sorry, long day: "...and its features..."
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1024>
__
___
Python-
Changes by Bill Janssen:
--
components: +Documentation
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1024>
__
___
Python-bugs-list mailing list
Unsubs
Bill Janssen added the comment:
I believe this is now fixed with patch 1018.
--
nosy: +janssen
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/iss
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/iss
Bill Janssen added the comment:
I believe issue 1018 now fixes this.
--
nosy: +janssen
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue889813>
___
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]&g
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/iss
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
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: +ja
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, 'Invali
New submission from Bill Janssen:
Just a note that the certificate in Lib/test/test_ssl.py will expire in
February of 2013 and have to be re-made.
--
components: Tests
messages: 55393
nosy: janssen
priority: low
severity: minor
status: open
title: certificate in Lib/test/test_ssl.py
Bill Janssen added the comment:
I'll take a look at this.
--
assignee: -> janssen
nosy: +janssen
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Bill Janssen added the comment:
Checked in.
--
assignee: nnorwitz -> janssen
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
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
Bill Janssen added the comment:
I'll take on providing the server example.
--
assignee: akuchling -> janssen
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Bill Janssen added the comment:
Fixed with 2.6 SSL support.
--
resolution: -> fixed
status: open -> closed
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.
Bill Janssen added the comment:
Fixed with the 2.6 SSL work.
--
resolution: -> fixed
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Bill Janssen added the comment:
Fixed in 2.6.
--
resolution: -> fixed
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
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'
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 t
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 <[
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 plat
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 ve
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
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 id
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
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
Bill Janssen added the comment:
Which versions of OS X, please? And which Xcode versions?
--
nosy: +janssen
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Bill Janssen added the comment:
Isn't this 1094?
--
nosy: +janssen
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1132>
__
___
Python-bugs-
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/is
Bill Janssen added the comment:
Fixed in rev 58097.
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1583946>
_
___
Python-bugs-list mailing list
Unsubs
Changes by Bill Janssen:
--
resolution: -> fixed
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1583946>
_
__
Bill Janssen added the comment:
Fixed in rev 58097.
--
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
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
_
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
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
Bill Janssen added the comment:
Sorry, you're absolutely right. Here's a corrected patch.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1203>
__
p
De
Changes by Bill Janssen:
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1203>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mai
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
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
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 c
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.p
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]>
<htt
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
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
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 ?
>
&
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 releasi
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
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 wr
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
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
Descrip
New submission from Bill Janssen:
Neal, a patch to get rid of the other ord() calls in ic.py.
--
assignee: nnorwitz
components: Library (Lib), Macintosh
files: d
keywords: py3k
messages: 56872
nosy: janssen, nnorwitz
priority: high
severity: normal
status: open
title: more uses of ord
Bill Janssen added the comment:
I still think the semantics are wrong here, but someone needs to close
this connection at some point, and right now the reference-counting
semantics of socket.close() are the only thing preventing a leak. So I
think my patch should not be applied. Instead, a
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
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: +gvan
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.
>
&
Bill Janssen added the comment:
Fixed in rev 58718
--
keywords: +py3k
resolution: accepted -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Bill Janssen added the comment:
Fixed in r58717
--
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1349>
__
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.pyt
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.
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.
B
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
wo
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 su
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 &l
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
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
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 j
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
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
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 memor
Bill Janssen added the comment:
Looks good to me, too.
--
nosy: +janssen
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1468>
__
___
Python-bugs-list
Bill Janssen added the comment:
What platform?
Bill
On Nov 20, 2007 11:21 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
>
> Christian Heimes added the comment:
>
> I don't see leaks when I run the tests with
>
> $ ./python Lib/test/regrtest.py -R:: test_ss
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
&
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: -> jansse
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 respo
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
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
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
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.
>
>
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
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
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
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
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
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:
&
Changes by Bill Janssen <[EMAIL PROTECTED]>:
--
resolution: -> works for me
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs
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,
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
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_l
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 directori
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
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
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
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 en
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
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 tes
Bill Janssen <[EMAIL PROTECTED]> added the comment:
I've added this into my patch.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3212>
___
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.
1 - 100 of 313 matches
Mail list logo
