Planet London Python

November 24, 2015

Menno Smits

IMAPClient 1.0.0

IMAPClient 1.0.0 is finally here! This is a monster release, bursting with new features and fixes.

Here's the highlights:

Enhanced TLS support: The way that IMAPClient establishes TLS connections has been completely reworked. By default, IMAPClient will attempt certificate verification and certificate hostname checking, and will not use known-insecure TLS settings and protocols. In addition, TLS parameters are now highly configurable.

This change necessitates that backwards compatibility has been broken, and also means that IMAPClient has a bunch of new dependencies. Please see the earlier blog article about the TLS changes as well as the release notes for more information.

STARTTLS support: When the server supports it, IMAPClient can now establish an encrypted connection after initially starting with an unencrypted connection using the STARTTLS command. The starttls method takes an SSL context object for controlling the parameters of the TLS negotiation.

Many thanks to Chris Arndt for his extensive initial work on this.

Robust search criteria handling: IMAPClient's methods that accept search criteria have been changed to provide take criteria in a more straightforward and robust way. In addition, the way the charset argument interacts with search criteria has been improved. These changes make it easier to pass search criteria and have them handled correctly.

Unfortunately these changes also mean that small changes may be required to existing code that uses IMAPClient. Please see the earlier blog article about the search changes as well as the release notes for more information.

Socket timeout support: IMAPClient now accepts a timeout at creation time. The timeout applies while establishing the connection and for all operations on the socket connected to the IMAP server.

Semantic versioning: In order to better indicate version compatibility to IMAPClient's users, the project will now strictly adhere to the Semantic Versioning scheme.

Performance optimisation for parsing message id lists: A short circuit is now used when parsing a list of message ids which greatly speeds up parsing time.

Installation via wheels: In addition to .zip and .tar.gz files, IMAPClient releases are now also available as universal wheels.

There have also been many other smaller fixes and improvements. See the release notes and manual for more details.

IMAPClient can be installed from PyPI (pip install imapclient) or downloaded via IMAPClient site.

This release couldn't have been possible with the amazing support of Nylas. If you're developing software that needs to deal with email, save yourself a whole lot of pain and check out their email platform. If you're after a modern, extensible, cross-platform email client check out N1.

November 24, 2015 04:45 AM

November 23, 2015

Python Anywhere

Security advisory: please change your PythonAnywhere MySQL password

tl;dr: On 19 November we were notified of a security vulnerability on PythonAnywhere. It could not have been used to access files on your PythonAnywhere storage, including your code, nor was any personally identifiable data in our databases exposed. We also have no indication that it was ever exploited. It was fixed within two hours of notification. However, as a precautionary measure, we are recommending that if you use MySQL on PythonAnywhere, you should change your MySQL password.

Here are the details.

On 19 November a user notified us of a security issue. In certain specific circumstances, a paying PythonAnywhere user could get a list of running processes on one of our console servers. We identified the problem and pushed a fix live 90 minutes later. We have analysed our logs, and cannot see any evidence of anyone having exploited this vulnerability, but clearly we cannot rule out the possibility that someone did exploit it in the past, or did so in a way we can't detect.

If someone did exploit it, they would have been able to see the usernames of all people logged in to that console server, and the full command lines of any processes they were running. They would not have had access to any user file storage, or to any of the databases where we store any personally identifiable information (for example, names and addresses). We do not store credit card numbers on our servers.

However, because full command lines for running processes were visible, any private information that you had on command lines could have been seen by such an attacker. This includes any MySQL passwords, as these are visible in the command line if you happen to have a MySQL console (started from the "Databases" tab) running on the server. Postgres passwords are not at risk, as these are never specified on a command line (unless you explicitly put them on a command line yourself).

As an example of a non-MySQL credential that might have been potentially exposed, imagine you're using a third-party service that sends text messages. Normally you would interact with this using Python, but if you're just playing around, you might use curl from a bash console like this:

curl -u '[YOUR ACCOUNT CREDENTIALS]' -d "message=Hello" -d "number=+15551234567"

You can see that if an attacker had used the vulnerability at exactly the right time, they might have seen those credentials.

Once again, we have no evidence to suggest that anyone has exploited this security hole, and it is now fixed. However, we strongly advise that as a precautionary security measure, you change any MySQL password you have set on the "Databases" tab within PythonAnywhere, and that you also change any other login credentials that might have been exposed on a command line.

If you have any questions, please email us at

by giles at November 23, 2015 06:33 PM