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+https://github.com/palaviv/cryptography.git@dh-impl-2#egg=cryptography
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.
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+https://github.com/palaviv/cryptography.git@dh-impl-2#egg=cryptography
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.