Re: [Python-Dev] ssl module and LibreSSL CVE-2018-8970

+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

Re: [Python-Dev] ssl module and LibreSSL CVE-2018-8970

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 >

[Python-Dev] ssl module and LibreSSL CVE-2018-8970

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 population. Introduction Python's ssl.match_hostname() function was a source o

Re: [Python-Dev] [ssl] The weird case of IDNA

> On 31 Dec 2017, at 18:07, Nathaniel Smith wrote: > > On Dec 31, 2017 7:37 AM, "Stephen J. Turnbull" > > wrote: > Nathaniel Smith writes: > > > Issue 1: Python's built-in IDNA implementation is wrong (implements > > IDNA 2003, not IDNA 2008). >

Re: [Python-Dev] [ssl] The weird case of IDNA

On Sun, Dec 31, 2017 at 05:51:47PM -0800, Nathaniel Smith wrote: > On Sun, Dec 31, 2017 at 5:39 PM, Steven D'Aprano wrote: > > On Sun, Dec 31, 2017 at 09:07:01AM -0800, Nathaniel Smith wrote: > > > >> This is another reason why we ought to let users do their own IDNA handling > >> if they want...

Re: [Python-Dev] [ssl] The weird case of IDNA

On Mon, Jan 1, 2018 at 12:39 PM, Steven D'Aprano wrote: > On Sun, Dec 31, 2017 at 09:07:01AM -0800, Nathaniel Smith wrote: > >> This is another reason why we ought to let users do their own IDNA handling >> if they want... > > I expect that letting users do their own IDNA handling will correspond

Re: [Python-Dev] [ssl] The weird case of IDNA

On Sun, Dec 31, 2017 at 5:39 PM, Steven D'Aprano wrote: > On Sun, Dec 31, 2017 at 09:07:01AM -0800, Nathaniel Smith wrote: > >> This is another reason why we ought to let users do their own IDNA handling >> if they want... > > I expect that letting users do their own IDNA handling will correspond

Re: [Python-Dev] [ssl] The weird case of IDNA

On Sun, Dec 31, 2017 at 09:07:01AM -0800, Nathaniel Smith wrote: > This is another reason why we ought to let users do their own IDNA handling > if they want... I expect that letting users do their own IDNA handling will correspond to not doing any IDNA handling at all. -- Steve

Re: [Python-Dev] [ssl] The weird case of IDNA

On Dec 31, 2017 7:37 AM, "Stephen J. Turnbull" < turnbull.stephen...@u.tsukuba.ac.jp> wrote: Nathaniel Smith writes: > Issue 1: Python's built-in IDNA implementation is wrong (implements > IDNA 2003, not IDNA 2008). Is "wrong" the right word here? I'll grant you that 2008 is *better*, but typ

Re: [Python-Dev] [ssl] The weird case of IDNA

Nathaniel Smith writes: > Issue 1: Python's built-in IDNA implementation is wrong (implements > IDNA 2003, not IDNA 2008). Is "wrong" the right word here? I'll grant you that 2008 is *better*, but typically in practice versions coexist for years. Ie, is there no backward compatibility issue w

Re: [Python-Dev] [ssl] The weird case of IDNA

On Sat, 30 Dec 2017 23:27:04 -0800 Nathaniel Smith wrote: > > We can bikeshed what the new name should be. Maybe set_sni_callback? > or set_server_hostname_callback, since the corresponding client-mode > argument is server_hostname? Or set_idna_servername_callback(). Regards Antoine. _

Re: [Python-Dev] [ssl] The weird case of IDNA

On Sat, Dec 30, 2017 at 2:28 AM, Antoine Pitrou wrote: > On Fri, 29 Dec 2017 21:54:46 +0100 > Christian Heimes wrote: >> >> On the other hand ssl module is currently completely broken. It converts >> hostnames from bytes to text with 'idna' codec in some places, but not >> in all. The SSLSocket.s

Re: [Python-Dev] [ssl] The weird case of IDNA

On Sat, Dec 30, 2017 at 7:26 AM, Stephen J. Turnbull wrote: > Christian Heimes writes: > > Questions: > > - Is everybody OK with breaking backwards compatibility? The risk is > > small. ASCII-only domains are not affected > > That's not quite true, as your German example shows. In some Orienta

[Python-Dev] [ssl] The weird case of IDNA

Christian Heimes writes: > tl;dr > This mail is about internationalized domain names and TLS/SSL. It > doesn't concern you if you live in ASCII-land. Me and a couple of other > developers like to change the ssl module in a backwards-incompatible way > to fix IDN support for TLS/SSL. Yes plea

Re: [Python-Dev] [ssl] The weird case of IDNA

ssl.match_hostname was added in Python 2.7.9, looks like Python 2 should be fixed as well. On Sat, Dec 30, 2017 at 3:50 PM Antoine Pitrou wrote: > > Thanks. So the change sounds ok to me. > > Regards > > Antoine. > > > On Sat, 30 Dec 2017 14:34:04 +0100 > Christian Heimes wrote: > > On 2017-12

Re: [Python-Dev] [ssl] The weird case of IDNA

Thanks. So the change sounds ok to me. Regards Antoine. On Sat, 30 Dec 2017 14:34:04 +0100 Christian Heimes wrote: > On 2017-12-30 11:28, Antoine Pitrou wrote: > > On Fri, 29 Dec 2017 21:54:46 +0100 > > Christian Heimes wrote: > >> > >> On the other hand ssl module is currently completely

Re: [Python-Dev] [ssl] The weird case of IDNA

On 2017-12-30 13:19, Skip Montanaro wrote: > Guido wrote: > > This being a security issue I think it's okay to break 3.6. might > even backport to 3.5 if it's easy? > > > Is it also a security issue with 2.x? If so, should a fix to 2.7 be > contemplated? IMO the IDNA encoding problem is

Re: [Python-Dev] [ssl] The weird case of IDNA

On 2017-12-30 11:28, Antoine Pitrou wrote: > On Fri, 29 Dec 2017 21:54:46 +0100 > Christian Heimes wrote: >> >> On the other hand ssl module is currently completely broken. It converts >> hostnames from bytes to text with 'idna' codec in some places, but not >> in all. The SSLSocket.server_hostnam

Re: [Python-Dev] [ssl] The weird case of IDNA

Guido wrote: This being a security issue I think it's okay to break 3.6. might even backport to 3.5 if it's easy? Is it also a security issue with 2.x? If so, should a fix to 2.7 be contemplated? Skip ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] [ssl] The weird case of IDNA

On Fri, 29 Dec 2017 21:54:46 +0100 Christian Heimes wrote: > > On the other hand ssl module is currently completely broken. It converts > hostnames from bytes to text with 'idna' codec in some places, but not > in all. The SSLSocket.server_hostname attribute and callback function > SSLContext.set

Re: [Python-Dev] [ssl] The weird case of IDNA

This being a security issue I think it's okay to break 3.6. might even backport to 3.5 if it's easy? On Dec 29, 2017 1:59 PM, "Christian Heimes" wrote: > Hi, > > tl;dr > This mail is about internationalized domain names and TLS/SSL. It > doesn't concern you if you live in ASCII-land. Me and a co

[Python-Dev] [ssl] The weird case of IDNA

Hi, tl;dr This mail is about internationalized domain names and TLS/SSL. It doesn't concern you if you live in ASCII-land. Me and a couple of other developers like to change the ssl module in a backwards-incompatible way to fix IDN support for TLS/SSL. Simply speaking the IDNA standards (interna

Re: [Python-Dev] SSL certificates recommendations for downstreampython packagers

Cory Benfield writes: > From a security perspective I think we have to discount the > possibility of administrator error from our threat model. I disagree in a certain sense, and in that sense you don't discount it -- see below. > A threat model that includes “defend the system against intrus

Re: [Python-Dev] SSL certificates recommendations for downstreampython packagers

> On 2 Feb 2017, at 03:38, Stephen J. Turnbull > wrote: > > Cory Benfield writes: > >> The TL;DR is: I understand Christian’s concern, but I don’t think >> it’s important if you’re very, very careful. > > But AIUI, the "you" above is the end-user or admin of end-user's > system, no? We know

Re: [Python-Dev] SSL certificates recommendations for downstreampython packagers

Cory Benfield writes: > The TL;DR is: I understand Christian’s concern, but I don’t think > it’s important if you’re very, very careful. But AIUI, the "you" above is the end-user or admin of end-user's system, no? We know that they aren't very careful (or perhaps more accurate, this is too fsc

Re: [Python-Dev] SSL certificates recommendations for downstreampython packagers

> On 1 Feb 2017, at 14:20, Steve Dower wrote: > > Sorry, I misspoke when I said "certificate validation callback", I meant the > same callback Cory uses below (name escapes me now, but it's unfortunately > similar to what I said). There are two callbacks in OpenSSL, one that allows > you to v

Re: [Python-Dev] SSL certificates recommendations for downstreampython packagers

rome has done it? Top-posted from my Windows Phone -Original Message- From: "Cory Benfield" Sent: ‎2/‎1/‎2017 2:03 To: "Steve Dower" Cc: "Christian Heimes" ; "David Cournapeau" ; "python-dev" Subject: Re: [Python-Dev] SSL certificates re

Re: [Python-Dev] SSL certificates recommendations for downstream python packagers

> On 31 Jan 2017, at 18:26, Steve Dower wrote: > > In short, I want to allow Python code to set OpenSSL's certificate validation > callback. Basically, given a raw certificate, return True/False based on > whether it should be trusted. I then have separate code (yet to be published) > impleme

Re: [Python-Dev] SSL certificates recommendations for downstream python packagers

On 30Jan2017 1310, Christian Heimes wrote: On 2017-01-30 21:50, Cory Benfield wrote: On 30 Jan 2017, at 13:53, David Cournapeau wrote: Are there any official recommendations for downstream packagers beyond PEP 476 ? Is it "acceptable" for downstream packagers to patch python's default cert

Re: [Python-Dev] SSL certificates recommendations for downstream python packagers

On 31 January 2017 at 14:54, Cory Benfield wrote: > > So C# applications are Windows-native safe on Windows, and are a crapshoot > elsewhere. For Java vs Python, I’d say we’re slightly ahead right now. That's precisely the sort of answer I was after. Many thanks. The additional detail is interes

Re: [Python-Dev] SSL certificates recommendations for downstream python packagers

> On 31 Jan 2017, at 09:56, Paul Moore wrote: > > On 31 January 2017 at 09:19, Cory Benfield wrote: >> >> In general, it is unwise to mix trust stores. If you want to use your OS’s >> trust store, the best approach is to use the OS’s TLS stack as well. At >> least that way when a user says “It

Re: [Python-Dev] SSL certificates recommendations for downstream python packagers

On Tue, Jan 31, 2017 at 9:19 AM, Cory Benfield wrote: > > On 30 Jan 2017, at 21:00, David Cournapeau wrote: > > > > On Mon, Jan 30, 2017 at 8:50 PM, Cory Benfield wrote: > >> >> >> > On 30 Jan 2017, at 13:53, David Cournapeau wrote: >> > >> > Are there any official recommendations for downstre

Re: [Python-Dev] SSL certificates recommendations for downstream python packagers

On 31 January 2017 at 09:19, Cory Benfield wrote: > > In general, it is unwise to mix trust stores. If you want to use your OS’s > trust store, the best approach is to use the OS’s TLS stack as well. At > least that way when a user says “It works in my browser”, you know it should > work for you t

Re: [Python-Dev] SSL certificates recommendations for downstream python packagers

> On 31 Jan 2017, at 09:33, Christian Heimes wrote: > > One small correction, it is possible to export some of the trust > settings to a TRUSTED CERTIFICATE and import them into OpenSSL. It works > correctly in 1.0.1 and since 1.0.2e or f. Trust settings are stored in > X509_AUX extension after

Re: [Python-Dev] SSL certificates recommendations for downstream python packagers

On 2017-01-31 10:19, Cory Benfield wrote: > >> On 30 Jan 2017, at 21:00, David Cournapeau > > wrote: >> >> >> >> On Mon, Jan 30, 2017 at 8:50 PM, Cory Benfield > > wrote: >> >> >> >> > On 30 Jan 2017, at 13:53, David Cournapeau >

Re: [Python-Dev] SSL certificates recommendations for downstream python packagers

> On 30 Jan 2017, at 21:00, David Cournapeau wrote: > > > > On Mon, Jan 30, 2017 at 8:50 PM, Cory Benfield > wrote: > > > > On 30 Jan 2017, at 13:53, David Cournapeau > > wrote: > > > > Are there any official recommendations for downstre

Re: [Python-Dev] SSL certificates recommendations for downstream python packagers

On 2017-01-30 22:19, David Cournapeau wrote: > Hm. Is this documented anywhere ? We have customers needing > "private/custom" certificates, and I am unsure where to look for. For full control it is advised to use a custom SSLContext that only loads the internal CA. https://docs.python.org/3/librar

Re: [Python-Dev] SSL certificates recommendations for downstream python packagers

On Mon, Jan 30, 2017 at 9:14 PM, Christian Heimes wrote: > On 2017-01-30 22:00, David Cournapeau wrote: > > > > > > On Mon, Jan 30, 2017 at 8:50 PM, Cory Benfield > > wrote: > > > > > > > > > On 30 Jan 2017, at 13:53, David Cournapeau > w

Re: [Python-Dev] SSL certificates recommendations for downstream python packagers

On 2017-01-30 22:00, David Cournapeau wrote: > > > On Mon, Jan 30, 2017 at 8:50 PM, Cory Benfield > wrote: > > > > > On 30 Jan 2017, at 13:53, David Cournapeau > wrote: > > > > Are there any official recommendations for downstr

Re: [Python-Dev] SSL certificates recommendations for downstream python packagers

On 2017-01-30 21:50, Cory Benfield wrote: > > >> On 30 Jan 2017, at 13:53, David Cournapeau wrote: >> >> Are there any official recommendations for downstream packagers beyond PEP >> 476 ? Is it "acceptable" for downstream packagers to patch python's default >> cert locations ? > > There *are

Re: [Python-Dev] SSL certificates recommendations for downstream python packagers

On Mon, Jan 30, 2017 at 8:50 PM, Cory Benfield wrote: > > > > On 30 Jan 2017, at 13:53, David Cournapeau wrote: > > > > Are there any official recommendations for downstream packagers beyond > PEP 476 ? Is it "acceptable" for downstream packagers to patch python's > default cert locations ? > >

Re: [Python-Dev] SSL certificates recommendations for downstream python packagers

On Mon, Jan 30, 2017 at 8:50 PM, Cory Benfield wrote: > > > > On 30 Jan 2017, at 13:53, David Cournapeau wrote: > > > > Are there any official recommendations for downstream packagers beyond > PEP 476 ? Is it "acceptable" for downstream packagers to patch python's > default cert locations ? > >

Re: [Python-Dev] SSL certificates recommendations for downstream python packagers

> On 30 Jan 2017, at 13:53, David Cournapeau wrote: > > Are there any official recommendations for downstream packagers beyond PEP > 476 ? Is it "acceptable" for downstream packagers to patch python's default > cert locations ? There *are* no default cert locations on Windows or macOS that c

Re: [Python-Dev] SSL certificates recommendations for downstream python packagers

On 2017-01-30 14:53, David Cournapeau wrote: > Hi, > > I am managing the team responsible for providing python packaging at > Enthought, and I would like to make sure we are providing a good (and > secure) out of the box experience for SSL. > > My understanding is that PEP 476 is the latest PEP t

[Python-Dev] SSL certificates recommendations for downstream python packagers

Hi, I am managing the team responsible for providing python packaging at Enthought, and I would like to make sure we are providing a good (and secure) out of the box experience for SSL. My understanding is that PEP 476 is the latest PEP that concerns this issue, and that PEP recommends using the

[Python-Dev] SSL sockets and settimeout

Am I correct in thinking that Python's newfangled socket.settimeout() feature does not play well with SSL wrapped sockets? Would there be any interest in making it so that it did? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/m

Re: [Python-Dev] SSL issues in Python stdlib and 3rd party code

On 8/13/2013 5:06 AM, Christian Heimes wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 CVE-2013-4238 has been signed to NULL bytes in subjectAltName issue. assigned... http://bugs.python.org/issue18709 http://www.openwall.com/lists/oss-security/2013/08/13/2 Should we assign a C

Re: [Python-Dev] SSL issues in Python stdlib and 3rd party code

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 CVE-2013-4238 has been signed to NULL bytes in subjectAltName issue. http://bugs.python.org/issue18709 http://www.openwall.com/lists/oss-security/2013/08/13/2 Should we assign a CVE to issue in ssl.match_hostname(), too? Even more projects have

Re: [Python-Dev] SSL issues in Python stdlib and 3rd party code

Hi, On Mon, 12 Aug 2013 19:18:17 +0200 Christian Heimes wrote: > related issue: Mozilla's certdata.txt and CKT_NSS_MUST_VERIFY_TRUST > - --- > > Recently I found bugs in curl's mk-ca-bundle.pl script, its cacert.pem > and in the CA

[Python-Dev] SSL issues in Python stdlib and 3rd party code

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello, last week Ryan Sleevi of the Google Chrome Security Team has informed us about about two issues in Python's SSL module. I already new about the cause of the first bug and suspected that our SSL module suffers from the second bug but I was una

Re: [Python-Dev] ssl improvements and testing question

On Fri, 07 Jun 2013 00:37:01 +0200 Christian Heimes wrote: > > I'm also thinking about OCSP support and X509v3 extension support for > _decode_certificate(). Both are a PITB ... Python has an easier and > better documented C API. Yes, OpenSSL's documentation is often a joke, unfortunately. > Qu

[Python-Dev] ssl improvements and testing question

Hi, I'm working on a couple of improvements for the ssl module: http://bugs.python.org/issue17134 http://bugs.python.org/issue18138 http://bugs.python.org/issue18143 http://bugs.python.org/issue18147 #17134 is going to provide a way to use Window's crypt32.dll to load CA certs from Window's CA c

Re: [Python-Dev] ssl

Am 07.06.2010 12:44, schrieb Kristján Valur Jónsson: Thanks martin. I did as you suggested, and by installing nasm (creating nasmw.exe as a copy of nasm.exe) and without installing perl, was able to build the 32 bit debug version. The 64 bit version didn't want to build, probably because of som

Re: [Python-Dev] ssl

ewis.de] > Sent: 5. júní 2010 23:52 > To: Kristján Valur Jónsson > Cc: python-dev@python.org > Subject: Re: [Python-Dev] ssl > > > In general, gettin all those "external" projects seem to be complex > to > > build. Is there a fast way? > > Run Tools\bui

Re: [Python-Dev] ssl

In general, gettin all those „external“ projects seem to be complex to build. Is there a fast way? Run Tools\buildbot\external.bat. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev U

Re: [Python-Dev] ssl

On 08:34 am, krist...@ccpgames.com wrote: Hello there. I wanted to do some work on the ssl module, but I was a bit daunted at the prerequisites. Is there anywhere that I can get at precompiled libs for the openssl that we use? In general, gettin all those "external" projects seem to be complex

[Python-Dev] ssl

Hello there. I wanted to do some work on the ssl module, but I was a bit daunted at the prerequisites. Is there anywhere that I can get at precompiled libs for the openssl that we use? In general, gettin all those "external" projects seem to be complex to build. Is there a fast way? What I wa

Re: [Python-Dev] ssl module

> 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

Re: [Python-Dev] ssl module

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

[Python-Dev] ssl module

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.) Like other Python users, I was a bit surprised by the

Re: [Python-Dev] SSL Certificate Validation

I think if you check the issue tracker, there's already a patch for this somewhere, IIRC. Bill Devin Cook wrote: > Ok, thanks for all the feedback. Just for clarity, I'll summarize > everything as I understand it: > > * OpenSSL does the all validation of the certificate itself. > (http://opens

Re: [Python-Dev] SSL Certificate Validation

Ok, thanks for all the feedback. Just for clarity, I'll summarize everything as I understand it: * OpenSSL does the all validation of the certificate itself. (http://openssl.org/docs/apps/verify.html) * httplib should have a way to enable validation of the certificate. * httplib should have a way

Re: [Python-Dev] SSL Certificate Validation

Martin v. Löwis wrote: > FWIW, I actually don't know the answer for sure, either, so I would have > to research this myself, too. In any case, _ssl.c is *not* the place > where any of the certificate validation actually happens - nor does it > happen elsewhere in the Python source code, IIUC. St

Re: [Python-Dev] SSL Certificate Validation

Bill Janssen wrote: > > Does it check that the host the socket is connected to is the same as > > what's given in the CN field in the certificate? > > No. That, in general, doesn't work very well. The IETF working group > on this is considering deprecating putting a hostname in the CN field at

Re: [Python-Dev] SSL Certificate Validation

> If this isn't the place to ask these kinds of questions, I apologise. > I can take the discussion elsewhere if I need to. It really depends on what "these questions" are. If your question is "I have this patch, is it correct?", then the question is entirely appropriate. If it is "I just have bar

Re: [Python-Dev] SSL Certificate Validation

On Tue, Jun 16, 2009 at 5:31 PM, Devin Cook wrote: >> But I really do believe that this is what he need to do next: >> familiarize himself with OpenSSL. There is a lot of APIs in that >> library, and it takes a while (i.e.: several months) to get >> productive, in particular since OpenSSL doesn't h

Re: [Python-Dev] SSL Certificate Validation

Devin Cook wrote: > Also, I have looked through the docs and code, but haven't been able to > figure out exactly what is included in certificate "validation". Is it just > validating the chain? Does it check the NotBefore and NotAfter dates? I believe so, but you'll have to check the OpenSSL cod

Re: [Python-Dev] SSL Certificate Validation

> But I really do believe that this is what he need to do next: > familiarize himself with OpenSSL. There is a lot of APIs in that > library, and it takes a while (i.e.: several months) to get > productive, in particular since OpenSSL doesn't have the most > intuitive API. Well, I realized this as

Re: [Python-Dev] SSL Certificate Validation

>> This question is really off-topic for python-dev. As a python-dev >> poster, you should do research upfront, and only post on what you >> consider facts. > > Martin, I told him to ask his question about _ssl internals on > python-dev as he is new, and looking to work on some of the > internals/

Re: [Python-Dev] SSL Certificate Validation

On Tue, Jun 16, 2009 at 3:23 PM, "Martin v. Löwis" wrote: >> I have a few questions about validating SSL certificates. From what I >> gather, this validation occurs in the OpenSSL code called from _ssl.c. >> Is this correct? > > This question is really off-topic for python-dev. As a python-dev > po

Re: [Python-Dev] SSL Certificate Validation

> I have a few questions about validating SSL certificates. From what I > gather, this validation occurs in the OpenSSL code called from _ssl.c. > Is this correct? This question is really off-topic for python-dev. As a python-dev poster, you should do research upfront, and only post on what you co

[Python-Dev] SSL Certificate Validation

Hi all, I have a few questions about validating SSL certificates. From what I gather, this validation occurs in the OpenSSL code called from _ssl.c. Is this correct? Also, I have looked through the docs and code, but haven't been able to figure out exactly what is included in certificate "validat

Re: [Python-Dev] ssl module, non-blocking sockets and asyncore integration

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

Re: [Python-Dev] ssl module, non-blocking sockets and asyncore integration

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

Re: [Python-Dev] ssl module, non-blocking sockets and asyncore integration

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 >

Re: [Python-Dev] ssl module, non-blocking sockets and asyncore integration

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

Re: [Python-Dev] ssl module, non-blocking sockets and asyncore integration

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

Re: [Python-Dev] ssl module, non-blocking sockets and asyncore integration

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

Re: [Python-Dev] ssl module, non-blocking sockets and asyncore integration

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

Re: [Python-Dev] ssl module, non-blocking sockets and asyncore integration

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

Re: [Python-Dev] ssl module, non-blocking sockets and asyncore integration

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

Re: [Python-Dev] ssl module, non-blocking sockets and asyncore integration

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.

Re: [Python-Dev] ssl module, non-blocking sockets and asyncore integration

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

Re: [Python-Dev] ssl - how to switch back to a plain text socket?

It's on my list. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] ssl - how to switch back to a plain text socket?

I provided a patch for adding TLS support to ftplib: http://bugs.python.org/issue2054 Bill, could you please take a look at it? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail

Re: [Python-Dev] ssl - how to switch back to a plain text socket?

On 20 Feb, 17:39, Bill Janssen <[EMAIL PROTECTED]> wrote: > > I'm not sure, I've seen more than one library and server supporting > > the CCC command. > > For example proftpd and tnftpd servers support it. > > But does anyone use it? > It is useful to permit passive connection behind firewall dev

Re: [Python-Dev] ssl - how to switch back to a plain text socket?

> > I suggest using socket.dup(sslsock) to simply create a non-encrypted > > copy of the socket, and switch to using that copy. There's no way to > > "unwrap" an SSLSocket. > > It does not seem to work: > > File "C:\python26\lib\ssl.py", line 115, in read >return self._sslobj.read(len) > ss

Re: [Python-Dev] ssl - how to switch back to a plain text socket?

On 20 Feb, 06:08, Bill Janssen <[EMAIL PROTECTED]> wrote: > I suggest using socket.dup(sslsock) to simply create a non-encrypted > copy of the socket, and switch to using that copy. There's no way to > "unwrap" an SSLSocket. It does not seem to work: File "C:\python26\lib\ssl.py", line 115, in

Re: [Python-Dev] ssl - how to switch back to a plain text socket?

> IIUC, RFC 4217 mandates that a TLS shutdown is exchanged (although they > apparently didn't read the TLS spec when they wrote the RFC, as the I'm pretty dubious about section 5 there. I don't think reverting to a plaintext state, once you've been in TLS, happens in real life to real connections

Re: [Python-Dev] ssl - how to switch back to a plain text socket?

> Perhaps that would be nice, but switching to plain-text use of the > socket can be coordinated outside the SSL protocol. I had an accessor > for SSL_shutdown, in an earlier version, but there were semantic > conflicts with the socket shutdown() method, and I didn't think anyone > would use it an

Re: [Python-Dev] ssl - how to switch back to a plain text socket?

> But shouldn't there be a way to invoke SSL_shutdown? You need to get > the close_notify alert message sent, IIUC. Perhaps that would be nice, but switching to plain-text use of the socket can be coordinated outside the SSL protocol. I had an accessor for SSL_shutdown, in an earlier version, but

Re: [Python-Dev] ssl - how to switch back to a plain text socket?

> I suggest using socket.dup(sslsock) to simply create a non-encrypted > copy of the socket, and switch to using that copy. There's no way to > "unwrap" an SSLSocket. But shouldn't there be a way to invoke SSL_shutdown? You need to get the close_notify alert message sent, IIUC. Regards, Martin _

Re: [Python-Dev] ssl - how to switch back to a plain text socket?

> I've read through ssl.py but I didn't notice anything useful. > It seems that ssl.SSLSocket class does not provide any method/facility > to switch back to a plain text socket state. I suggest using socket.dup(sslsock) to simply create a non-encrypted copy of the socket, and switch to using that

[Python-Dev] ssl - how to switch back to a plain text socket?

Hi all, I'm trying to extend the base ftplib module to add SSL/TLS support as described in RFC-4217 (see also issue 2054). RFC-4217 defines a certain command ("CCC") which permit to return to a plain text socket state without closing the connection. That is useful since that, being FTP a port-hoppi

Re: [Python-Dev] ssl module integration with asyncore

> 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

Re: [Python-Dev] ssl module integration with asyncore

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

Re: [Python-Dev] ssl module integration with asyncore

> 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

Re: [Python-Dev] ssl module integration with asyncore

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

Re: [Python-Dev] ssl module integration with asyncore

> 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

Re: [Python-Dev] ssl module integration with asyncore

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

  1   2   >