+1. Thanks!
Which tests?
On Wednesday, April 4, 2018, Christian Heimes wrote:
> Hi,
>
> I like to share the story of a critical security bug with you. Contrary
> to other issues in TLS/SSL, it's a story with happy ending. Nobody was
> harmed. The bug was fixed before it affected the general pop
Nice work! Something to add to our "finding C compiler bugs" list of
accomplishments. 😁
On Wed, Apr 4, 2018, 13:39 Christian Heimes, wrote:
> Hi,
>
> I like to share the story of a critical security bug with you. Contrary
> to other issues in TLS/SSL, it's a story with happy ending. Nobody was
>
> Is there a place where the status of the ssl module is summarized
The documentation of the ssl module should describe its features
correctly and precisely.
> or a better place to discuss this? I could try to provide contributions or
> further details if appropriate.
For contributions, this is
Bruno Harbulot wrote:
> Hello,
>
> I would like to ask a few questions and suggestions regarding the ssl
> module (in Python 2.6). (I gather from [1] that there is some effort
> going on to enhance the ssl API, but I'm not sure if this is the right
> place to discuss it.)
>
> Is there a place w
Some good news: I finally figured out how to modify asyncore to make
it properly handle the non-blocking ssl-handshake.
I provided a patch for test_ssl.py in issue 3899.
Bill, could you please review it?
--- Giampaolo
http://code.google.com/p/pyftpdlib/
On 18 Set, 00:49, "Giampaolo Rodola'" <[EM
Ok, here's some news, in case they can be of some interest.
I managed to write an asyncore disptacher which seems to work.
I used my test suite against it and 70 tests passed and 2 failed.
The tests failed because at a certain point a call to do_handhsake
results in an EOF exception, which is very
Bill Janssen wrote:
> Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
>
>> On Wed, 17 Sep 2008 10:40:01 PDT, Bill Janssen <[EMAIL PROTECTED]> wrote:
>>> Ah, now I remember. It seems that sometimes when SSL_ERROR_WANT_READ
>>> was returned, things would block; that is, the "handle_read" method on
>
Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> On Wed, 17 Sep 2008 10:40:01 PDT, Bill Janssen <[EMAIL PROTECTED]> wrote:
> >Ah, now I remember. It seems that sometimes when SSL_ERROR_WANT_READ
> >was returned, things would block; that is, the "handle_read" method on
> >asyncore.dispatcher was n
On Wed, 17 Sep 2008 10:40:01 PDT, Bill Janssen <[EMAIL PROTECTED]> wrote:
Ah, now I remember. It seems that sometimes when SSL_ERROR_WANT_READ
was returned, things would block; that is, the "handle_read" method on
asyncore.dispatcher was never called again, so the SSLSocket.recv()
method was nev
Ah, now I remember. It seems that sometimes when SSL_ERROR_WANT_READ
was returned, things would block; that is, the "handle_read" method on
asyncore.dispatcher was never called again, so the SSLSocket.recv()
method was never re-called. There are several levels of buffering going
on, and I never f
Giampaolo Rodola' <[EMAIL PROTECTED]> wrote:
> In the meanwhile I noticed something in the ssl.py code which seems to
> be wrong:
>
> def recv (self, buflen=1024, flags=0):
> if self._sslobj:
> if flags != 0:
> raise ValueError(
> "non-z
Giampaolo Rodola' <[EMAIL PROTECTED]> wrote:
> I change my question: how am I supposed to know when the SSL hanshake
> is completed? When pending() returns False?
When do_handshake() doesn't raise an exception.
Bill
___
Python-Dev mailing list
Python-D
Giampaolo Rodola' <[EMAIL PROTECTED]> wrote:
> 2 - By reading ssl.py code I noticed that when do_handshake_on_connect
> flag is False the do_handshake() method is never called. Is it
> supposed to be manually called when dealing with non-blocking sockets?
Yes. Look at the example client in Lib/t
Sorry, ignore my 2nd question, I see now that you already gave a very
clear answer in your first message.
I change my question: how am I supposed to know when the SSL hanshake
is completed? When pending() returns False?
If so I'd recommend to document the method.
--- Giampaolo
http://code.google.
I've tried to modify my existing asyncore-based code but I'm
encountering a lot of different problems I didn't manage to fix.
It seems that playing with the do_handshake_on_connect flag doesn't
make any difference.
I guess that without some kind of documentation describing how to deal
with non-bloc
> No, the SSL code should NOT be allowed to block anything in any case,
> even though the handshake is still not completed, in which case just
> retry it at a later time.
That's why there's "do_handshake_on_connect" in the first place. I'm
just talking about what the SSL module should do if you d
On 29 Nov, 06:00, Bill Janssen <[EMAIL PROTECTED]> wrote:
> I think it's simpler to let the SSL module do it, even though it comes
> at the expense of blocking the thread till the handshake is complete.
> That's essentially what happens already. The question is whether the
> SSL setup code is al
> IMO, it's not reasonable since the application could use something
> different than select.select(), like select.poll() or something else
> again.
As I said before, you can do away with select or poll altogether if
you write a state machine for your asyncore dispatcher. Asyncore will
tell you w
On 29 Nov, 03:27, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > It does raise the same exception.
>
> Hmmm, not in my version.
>
> > Are there plans for fixing this?
>
> Yes, it's fixed in my CVS, and I'll upload a new version to PyPI when
> I get a chance.
>
> > Using that kind of workaround is not
> It does raise the same exception.
Hmmm, not in my version.
> Are there plans for fixing this?
Yes, it's fixed in my CVS, and I'll upload a new version to PyPI when
I get a chance.
> Using that kind of workaround is not acceptable in any case (select
> module shouldn't even get imported when u
On 29 Nov, 00:26, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > I tried to write a simple asyncore-based server code, then I used a
> > simple client to establish a connection with it.
> > Once the client is connected server raises the following exception:
>
> I think this is a bug. Thanks!
You're
> I tried to write a simple asyncore-based server code, then I used a
> simple client to establish a connection with it.
> Once the client is connected server raises the following exception:
I think this is a bug. Thanks!
The issue is that the internal call to do_handshake() doesn't handle
non-b
I tried to write a simple asyncore-based server code, then I used a
simple client to establish a connection with it.
Once the client is connected server raises the following exception:
--- snippet ---
C:\Documents and Settings\billiejoex\Desktop\test>test.py
[]127.0.0.1:3003 Connected.
Traceback
> I downloaded this one:
> http://pypi.python.org/pypi/ssl/1.12
Yes, that's the one.
> ...which seems to contain the same test-suite used in the current
Not quite.
> Python 2.6 distribution available here:
> http://svn.python.org/snapshots/
> I looked into test/test_ssl.py but I didn't find any
On 26 Nov, 19:23, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > Hi there,
> > since ssl module is still in development I thought it would have been
> > better asking such question here instead of on comp.lang.python.
> > I'm interested in using the ssl module with asyncore but since there's
> > no re
> Hi there,
> since ssl module is still in development I thought it would have been
> better asking such question here instead of on comp.lang.python.
> I'm interested in using the ssl module with asyncore but since there's
> no real documentation about it yet I've been not able to write
> somethin
26 matches
Mail list logo
