[issue37777] imap breaks on OpenSSL 1.1.1 when SNI is enforced
New submission from Casey : OpenSSL 1.1.1 is an LTS release that will see long maintenance, and Ubuntu 18.04 LTS has now upgraded from 1.1.0 to 1.1.1. However, with this upgrade, TLS 1.3 allows email clients to require an SNI for the handshake to succeed. Because the 2.7 imap module does not enforce or provide SNI to the handshake, Python 2.7 with OpenSSL 1.1.1 will break if an email client requires the SNI hostname. Relevant 2.7 file: https://github.com/python/cpython/blob/2.7/Lib/imaplib.py Right now, the only email client that enforces an SNI header to connect is GMail, and this is why no SSL or imap tests would currently fail due to this issue. This issue was addressed in Python 3.4 but not backported as far as I've been able to tell: https://github.com/python/cpython/commit/7243b574e5fc6f9ae68dc5ebd8252047b8e78e3b With a few releases still planned for Python 2.7 before EOL according to Pep 373, while this is not directly a security issue it does block the use of the latest OpenSSL package and seems like a useful inclusion to the last few releases. Happy to submit a backport PR (in progress) if that's likely. Reproduce steps here: https://github.com/CaseyFaist/reproduceSNIcase -- assignee: christian.heimes components: SSL messages: 349131 nosy: alex, cfactoid, christian.heimes, dstufft, janssen priority: normal severity: normal status: open title: imap breaks on OpenSSL 1.1.1 when SNI is enforced type: crash versions: Python 2.7 ___ Python tracker <https://bugs.python.org/issue3> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37777] imap breaks on OpenSSL 1.1.1 when SNI is enforced
Casey added the comment: Update: After digging further (and enabling the "Less secure app access" setting on the test Google account) it looks like Python 2.7 caps TLS at 1.2 rather than using 1.3 when OpenSSL is upgraded. This prevents breakage, and it looks like the SSLSocket class silences the handshake complaints. If this were an active branch, this could be worth revisiting - but since 2.7 is soon to be EOL and we can't reproduce the breakage, not sure it's worth it. -- stage: -> resolved status: open -> closed type: crash -> behavior ___ Python tracker <https://bugs.python.org/issue3> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4544] textwrap: __all__ atribute missing 'dedent' functino
New submission from Casey McGinty <[EMAIL PROTECTED]>: >From textwrap.py: 46863 2006-06-11 19:42:51Z tim.peters The __all__ define in this module is missing the helper function 'dedent'. This causes pydoc to not the list the function correctly. Secondly, it also prevents 'dedent' from being imported when using 'from textwrap import *' (Yes, yes, I know this should never be done. Hence why it is probably never noticed by anyone.) -- components: Extension Modules messages: 76986 nosy: wolfdown severity: normal status: open title: textwrap: __all__ atribute missing 'dedent' functino type: feature request versions: Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4544> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4544] textwrap: __all__ atribute missing 'dedent' function
Changes by Casey McGinty <[EMAIL PROTECTED]>: -- title: textwrap: __all__ atribute missing 'dedent' functino -> textwrap: __all__ atribute missing 'dedent' function ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4544> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3518] multiprocessing: BaseManager.from_address documented but doesn't exist
Casey McGinty added the comment: I would like to open this ticket back up. Python 2.6.2 docs still reference unimplemented 'from_address' method. http://docs.python.org/library/multiprocessing.html#multiprocessing.managers.BaseManager.from_address BaseManager.__reduce__ method also calls unimplemented 'from_address' method. This looks like a bug since there is no docs or comments that indicate it is as an abstract method. -- nosy: +casey.mcgi...@gmail.com ___ Python tracker <http://bugs.python.org/issue3518> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5862] multiprocessing 'using a remote manager' example errors and possible 'from_address' code leftover
Changes by Casey McGinty : -- nosy: +cmcginty ___ Python tracker <http://bugs.python.org/issue5862> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6589] smtpd.SMTPServer can cause asyncore.loop to enter infinite event loop
New submission from Casey McGinty : When subclass of smtpd.SMTPServer, it is possible the get asyncore.loop to enter an infinite loop where the following output is shown: . warning: unhandled write event warning: unhandled read event warning: unhandled write event warning: unhandled read event warning: unhandled write event warning: unhandled read event warning: unhandled write event warning: unhandled read event warning: unhandled write event warning: unhandled read event warning: unhandled write event warning: unhandled read event To reproduce: 1) Init SMTPServer class instance inside of Thread class and call asyncore.loop() 2) Init second SMTPServer class instance from a second Thread class, binding to the same address and port. The SMTPServer instance will raise an exception that socket cannot bind to the port in use. The socket exception must be caught at some level, and the program execution allowed to continue. 3) First SMTPServer thread will enter infinite event loop. Analysis: When the exception is raised in the second SMTPServer instance, the new instance has already registered itself with the asyncore library (ex: 'asyncore.dispatcher.__init__(self)'). There is no code in the SMTPServere.__init__ method that catches the exception raised, caused by the failed bind attempt. After the exception is caught, the first thread continues to run, but asyncore is in an invalid state because it still has the registration of the second SMTPServer instance that never completed. Workaround and Proposed Fix: A viable workaround seems to be catching the raised exception in __init__ method of the SMTPServer subclass, and call self.close() before re-raising the exception: class MySmtpServer( smtpd.SMTPServer, object ): def __init__( self, **kwargs ): try: super( _SmtpSink, self).__init__(**kwargs) except Exception as e: self.close() # cleanup asyncore after failure raise For a long term fix, I would recommend performing the asyncore.dispatcher.close() method call in the SMTPServer.__init__() method. -- components: Library (Lib) messages: 91002 nosy: cmcginty severity: normal status: open title: smtpd.SMTPServer can cause asyncore.loop to enter infinite event loop versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue6589> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6605] smtplib.SMTP.sendmail() rejected after quit(), connect() sequence, no HELO
New submission from Casey McGinty : The smtplib.SMTP.quit() method does not reset the 'helo_resp' and 'ehlo_resp' instance attributes. During the next smtplib.SMTP.sendmail(), the HELO/EHLO commands are not sent, and may cause the remote SMTP service to reject the message, due to improper protocol handshaking. To fix, self.helo_resp and self.ehlo_resp should be set to 'None' in the smtplib.SMTP.quit() method. -- components: Library (Lib) messages: 91107 nosy: cmcginty severity: normal status: open title: smtplib.SMTP.sendmail() rejected after quit(),connect() sequence, no HELO versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue6605> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6605] smtplib.SMTP.sendmail() rejected after quit(), connect() sequence, no HELO
Casey McGinty added the comment: Sorry, duplicate of #4142 -- type: -> behavior ___ Python tracker <http://bugs.python.org/issue6605> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6589] smtpd.SMTPServer can cause asyncore.loop to enter infinite event loop
Casey McGinty added the comment: This is how it gets in an "invalid state". Not sure why you can't look at the code and see the mistake. "There is no code in the SMTPServere.__init__ method that catches the exception raised, caused by the failed bind attempt. After the exception is caught, the first thread continues to run, but asyncore is in an invalid state because it still has the registration of the second SMTPServer instance that never completed." As far as running in a thread. I have a program that needs must start and stop the SMTPServer dynamically. I did this by putting SMTPServer in a thread. Maybe there is another way to do it, but if you are not going to support this, then it should be documented. -- ___ Python tracker <http://bugs.python.org/issue6589> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6589] smtpd.SMTPServer can cause asyncore.loop to enter infinite event loop
Casey McGinty added the comment: I attached a simple script that reproduces the report issue. I hope it helps. -- Added file: http://bugs.python.org/file17807/smtp_test.py ___ Python tracker <http://bugs.python.org/issue6589> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27808] os.waitpid does not return (0, 0) when child has not exited (FreeBSD)
New submission from Casey Lucas: I'm not sure if this a Python issue or a FreeBSD issue but the return value from os.waitpid is not reliably (0,0) on FreeBSD when the WNOHANG is used and the child process has not yet exited. Python docs say that the return value will be (0,0) but this is not the case. I believe it is because the FreeBSD implementation of waitpid writes an uninitialized value to the status field when a child process is not available. See also: http://stackoverflow.com/questions/38984449/is-status-value-from-os-waitpid-unreliable-when-os-wnohang-is-used-under-freebsd Maybe this is just a documentation issue? Or does the C code in the Python library need to handle this case? -- components: FreeBSD, Library (Lib) files: waitpid_test.py messages: 273167 nosy: Casey Lucas, koobs priority: normal severity: normal status: open title: os.waitpid does not return (0,0) when child has not exited (FreeBSD) versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file44161/waitpid_test.py ___ Python tracker <http://bugs.python.org/issue27808> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
