OAuth2 authentication for offline email clients

More than a year ago, in my first post on this blog, I described my head in the cloud, feet on the ground strategy for offline email access. At that time, my solution (based on offlineimap) required me to store my email password in my Gnome keyring. This is far from satisfactory because as I explained in my blog post on using encryption, I do not like to keep important passwords in the Gnome Keyring. For that, I use a KeePass password file in an encrypted file system. This means that I need three passwords to get to access my important passwords: first to login to the computer, second to mount my encrypted volume and third to open the password manager. On the other hand, I need only my login password to get to the less important passwords sitting in the Gnome Keyring. In my view, email passwords are among the most important ones, and it unfortunate that to use offlineimap, I had to store this critical stuff in the Gnome Keyring.

The solution is to use OAuth2. In the last year or so, offlineimap has acquired the capability to use OAuth2, and now I have completed my migration to this method. As part of this process, I sat down and read the official document on OAuth 2.0 Threat Model and Security Considerations. That made me uncomfortable with the suggested approach in offlineimap (and many other software as well) of storing the OAuth2 refresh token in plain text in the configuration file. It might be acceptable if the home partition is encrypted, but as I explained in my Using Encryption post, that is not how my laptop is set up. I therefore came up with the idea of storing the refresh token in the Gnome Keyring. Since it is possible to use arbitrary python code for almost all settings in the offlineimap configuration file, this is easy.
Continue Reading

Migrating from R to Python

Many years ago, I shifted from Microsoft Excel and LibreOffice Calc to R data frames as my primary spreadsheet tool. This was one of the earliest steps in my ongoing move from bloat to minimalism (see my three blog posts on this process). Shifting to R yielded many benefits:

  • Greater readability and maintainability
  • Version control
  • Reusable code
  • Dynamic generation of reports and presentations from computed data using LaTex and knitr
  • Production quality graphics and charts using plain R graphics and more importantly ggplot
  • Access to a comprehensive library of statistical and quantitative finance tools written in R

Over the last few months, I have been shifting from R to Python for most of my work. The primary reason for making this change is that Python is a full fledged programming language unlike R which is primarily a statistical language which has been extended to do a lot of other things. A few years ago (when I first shifted to R), Python was totally unsuitable for use as a spreadsheet because the language was primarily designed to work with scalars rather than vectors and matrices. But in recent years, the Python tool sets (NumPy, SciPy, pandas, matplotlib, statsmodels, scikit-learn) have developed rapidly and now goes beyond the capabilities of R in many respects. Jake VanderPlas’s keynote talk at the Scipy 2015 Conference is an excellent introduction to this entire set of tools. Overall, I am very happy with the pandas implementation of data frames based on NumPy arrays; the best features of R have been preserved.
Continue Reading