Skip to main content

Driveby contribution to Python Cryptography

While at PyConAU 2016 I attended the Monday sprints and spent some time looking at a proposed feature I hoped would soon be part of cryptography. As most readers of this blog will know, cryptography is a very respected project within the Python ecosystem and it was an interesting experience to see how such a prominent open source project handles contributions and reviews.

The feature in question is the Diffie-Hellman Key Exchange algorithm used in many cryptography applications. Diffie-Helman Key Exchange is a way of generating a shared secret between two parties where the secret can't be determined by an eavesdropper observing the communication. DHE is extremely common - it is one of the primary methods used to provide "perfect forward secrecy" every time you initiate a TLS connection to an HTTPS website. Mathematically it is extremely elegant and the inventors were the recipients of the 2015 Turing award.

I wanted to write about this particular contribution because many people seem to expect that the only open source contributions are writing code, and also I wanted to highlight that good things take time!
So at PyConAU; I knew that a cryptography contributor Aviv Palivoda had opened a pull request in May #2914 and I wanted to see if it was going to work for my purposes and if I could help push it along!

One great feature of pip is that you can install directly from a git branch, so in a new virtual environment installing from the pull request's source was as easy as adding a new line to my requirements file:

-e git+

After a pip install we now can import the modified version of cryptography and test the new feature. The details aren't relevant for our purposes here so I'll skip the client test code. My simple script tested my understanding of the new DHKE api. After I got everything working I provided my feedback on the PR - I'd identified a few small inconsistencies in the documentation.

The author palaviv responded and invited me to carry out some of the suggested changes. To do this I added a few commits (via a PR) to his branch which, when accepted, propagated to the PR on the main cryptography repository. These were small updates like this:

While waiting for a formal review there were a few automated checks that needed to pass: documentation tests had to build and run in a reasonable time, code coverage had to be 100% etc. The github project is setup to automatically carry out these small number of checks before a PR can be merged:

Before too long, in early November, reaperhulk (Paul Kehrer) carried out an in-depth code review and raised further concerns which palaviv addressed in short order. It looks like all the checks are passing and the code review will soon be signed off meaning the new feature is ready to land in master. All going according to plan it is scheduled to be released in cryptography version 1.7 which should be out in December.

Not every contribution to open source has to be writing code, and not every contribution will be accepted straight away. My intention when I started to look at this PR was just to see how it worked and perhaps just by commenting give it a bump in attention. In fact palaviv based it off an earlier, rejected, pull request made by someone else. Open source is full of stories of people picking something up and running with it.

I really enjoyed seeing this feature evolve, and playing a small part. Finally I'd like to say how very impressed I am by the dedicated individuals on the cryptography team for keeping high standards ensuring quality software is produced. As you would expect from a project like cryptography every new feature or major change clearly gets vetted with a very careful code review.

Popular posts from this blog

My setup for downloading & streaming movies and tv

I recently signed up for Netflix and am retiring my headless home media pc. This blog will have to serve as its obituary. The box spent about half of its life running FreeNAS, and half running Archlinux. I’ll briefly talk about my experience with FreeNAS, the migration, and then I’ll get to the robust setup I ended up with.

The machine itself cost around $1000 in 2014. Powered by an AMD A4-7300 3.8GHz cpu with 8GB of memory. A SilverStone DS380 case is both functional, quiet and looks great. The hard drives have been updated over the last two years until it had a full compliment of 6 WD Green 4TiB drives - all spinning bits of metal though.

Initially I had the BSD based FreeNAS operating system installed. I had a single hard drive in its own ZFS pool for TV and Movies, and a second ZFS pool comprised of 5 hard drives for documents and photos.

FreeNAS is straight forward to use and setup, provided you only want to do things supported out of the box or by plugins. Each plugin is install…

Python, Virtualenv and Docker

Unsurprisingly I use some very popular Scientific Python packages like Numpy, Scipy and Scikit Learn. These packages don't get on that well with virtualenv and pip as they take a lot of external dependencies to build. These dependencies can be optional libraries like libblas and libatlas which if present will make Numpy run faster, or required dependencies like a fortran compiler.

Back in the good old days you wouldn't pin all your dependency versions down and you'd end up with a precarious mix of apt-get installed and pip installed packages. Working with other developers, especially on different operating system update schedules could be a pain. It was time to update your project when it breaks because of a dependency upgraded by the operating system.

Does virtualenv fully solve this? No, not when you have hard requirements on the binaries that must be installed at a system level.

Docker being at a lower level gives you much more control without adding too much extra comp…