Name

Jacob Adams

Contact/Email/IRC nick

Homepage: http://tookmund.github.io/

Blog: https://tookmund.github.io/blog/

Email: <tookmund@gmail.com>

IRC: tookmund on OFTC

Background

I am a mostly self-taught freshman Computer Science Major from the College of William and Mary in Virginia, USA. I took CS in high school up to the AP level (college 100 level equivalent), I've taken 200-level courses this current semester and the previous one, and I'll be taking a 300-level CS course next semester. I've worked in Python a bit for my past few classes and I feel fairly confident in the language. I've set up a couple GPG keys now and I use a Yubikey 4 to manage my GPG key, so I have some experience with that as well.

I first found Debian a few years ago when trying out every operating system I could get my hands on. Others were perhaps easier to use and install, but I found in Debian a community of volunteers interested in making a cool thing with free software and and open community as its top priorities. I've been following d-devel ever since, and I've installed Debian on pretty much every computer I've owned since then. Now I maintain a couple small packages of the thousands, but I've always wanted to have a bigger impact on this project. I've learned a lot from this community and have really come to understand and respect the importance and power of open source in the modern world. Debian has brought together an ecclectic team of people from all over the world to make an operating system I use on a daily basis.I want to do what I can to give back. It seems only right considering all that you've given to me.

Project title

PGP Clean Room Live CD

Problem

In the modern era of government snooping and almost continuous data breaches. It's incredibly difficult to establish trust in this environment, especially in a decentralized project like Debian. Encryption technology like GPG can offer a solution to these problems of confidentiality, authentication, and non-repudiation. GPG, however, has a significant learning curve especially when it comes to generating and storing private key material safely. Managing keys sucessfully requires a through knowledge of how GPG works, far more than the average contributor really needs. Some application is needed to walk new contributors through this process without overwhelming them with the complexities of GPG.

Project synopsis

Building a TUI application for the PGP Clean Room Live CD to walk a user through safely creating and storing a PGP key offline and managing said key for simple operations like revocation and keysigning.

Project details

Using python-newt, Python's GPGME bindings, and some of the scripts already written for the clean room project, I will write an application that manages the creation of an encrypted RAID1 device for GPG key storage, generates new keys to store there, and creates subkeys for daily use. It will also support PGP smartcards and manage key signing and revocation. It should be opinionated and provide the user with a sane gpg.conf as well as a method for easily importing their public key (and subkeys, if they don't have a smartcard) to their main computer.

I have written up a potential workflow:

Proposed Workflow

I've also begun working on this project based on the existing repository and one can find my work on salsa.d.o.

Tools

My plan is to use primarily IRC and email for communication on this project, but I'm open to any other tools that work best for my mentors.

I've never used a project management solution before but I've done some research and I'm currently learning how to use kanban boards via Wekan on storm.d.o.

My primary code editor is Vim.

I use the i3 window manager.

My current plan is to work on this project at home on my desktop, an amd64 computer with an Intel i5-6500, 16 GB of RAM, and an AMD RX 480 running Debian Testing. I may also do some work from my 5th-gen Thinkpad X1 Carbon running Debian Stretch from my local public library.

When I get stuck

My first resource is, of course, my mentors, but they may not always be available.

I will use mailing lists like the gnupg-users list and the pki-clean-room list (for as long as it is still up) to help when I am stuck on sometime. python-newt is fairly readable, and GPGME itself is extensively documented. I've already read some of the python-newt source code as well as the source code for the Python's GPGME bindings and will consult that when stuck.

I expect the most challenging part to be managing the user's removable media in a sane and secure way. Thus, as can be seen from my plan, I will look into this once the community bonding period starts so that I can search for resources on this difficult part of my project as soon as possible.

I also expect that triggering the generation of PGP keys directly on a smartcard from Python could be tough as it appears that GPGME does not support it. I've allocated two weeks to figuring it out in my schedule because I suspect it could be difficult.

Benefits to Debian

PGP is very important to the Debian Project as a whole. Its web of trust secures our entire operating system. Getting started safely with GPG is very difficult to do. GPG is a complex command-line tool that does an incredible number of things and though there are many, many guides on the Internet on how to use it correctly, many contradict each other and are often confusing. GPG is a significant roadblock to getting actual work done on the project. Contributors would much rather actually contribute to the project and do what they came to do instead of struggling through a complex process to generate some magic numbers. Thus creating an application to help new contributors through this process will benefit Debian and the many other open source projects that rely on GPG to secure themselves.

Offline backups of one's master key and subkeys is place where GPG currently fails. One should probably be generating their keys offline, maybe even on a seperate machine depending on their personal threat model. You also should never compare just a 32-bit key id (see https://evil32.com/ ), but GPG explains none of this. For the average contributor, they must just hope to find a good tutorial that covers current best practices and hope it's not out of date.

This project will not only save new contributors from having to deal with GPG directly, but also allow old contributors to manage their old keys and create new ones with minimal fuss. The keysigning process is still going to be more of a social and geographical problem than a technical one, but anything that we can do to reduce the technical overhead of this difficulty, the better. Making keysigning easier for offline master keys might even encourage people to sign more keys that they trust.

With GPG, the easiest solution is often not the best one (see storing master keys directly on one's computer) and so encouraging best practices by making them easier seems like a good approach. GPG's standard command-line tools are complex and most best-practices involve the user having to learn much more about the internals of GPG than they will ever need on a regular basis (knowing private vs. public key is good, but knowing the syntax of gpg.conf is really unnecessary for most).

Freed from having to learn the complexities of GPG, contributors will be able to return to doing what they wanted to do in the first place, that is contribute to Debian and make our operating system better, each in their own way.

Deliverables / Final Aim

Create a secure PGP Clean Room Live CD and accompanying application that will create and manage PGP keys in a safe and secure manner. Anyone who can install Debian should also be able to easily use this application to simplify the process of becoming a contributor. It should run anywhere Debian can and will have the ability to support every language Debian supports. This application should be available to other communities and should be hopefully easily adoptable by them. I hope to encourage better and easier use of GPG for anyone who needs it.

More realistically, I just expect that some people who might otherwise have spent an evening frustrated by GPG (as I have few a times myself) will use this application to save time, ensure strong use of GPG, and enable them to focus on what they actually want to do, rather than spend time figuring out GPG.

Project schedule

I will begin work as soon as the weekend of May 12th.

Community Bonding Period

Week 1

Week 2

Week 3

Week 4

Evaluation Period 1 / Week 5

Week 6

Week 7

Week 8

Evaluation Period 2 / Week 9

Week 10

Week 11

Week 12

Week 13

Evaluation Period 3 / Week 14

Exams and other commitments

My last exam is on May 9th, so I will not have any schoolwork to worry about during the project.

Other summer plans

I have structured my vacations and such so that I do not have anything during the coding period that would take me away from my project.

Why Debian?

Debian is one of the most foundational open source projects and also one of the most under-appreciated. For me as a somewhat new contributor, the project can be very intimidating at times and it often seems difficult to get involved without a very clear idea of exactly how one can be helpful. The barrier to new contributors should thus be as low as safely possible and I would love to help with that as much as I can.

My previous Debian contributions

I maintain a couple packages in Debian currently but haven't been involved much otherwise. I'd like to be more involved than just a couple minor packages and this seemed like the perfect opportunity.

Are you applying for other projects in SoC?

No, I have no plans to do so at this time.

Recent Contributions

Most of the programming I've done in the past year has been for class so I can't link to it unfortunately. I built data structures in Python for class, including binary trees, linked lists, deques, queues, and stacks.

Some interesting projects I've worked on in the past: