1 Google Summer of Code 2014
Dominik Schürmann edited this page 2014-05-20 05:33:07 -07:00

This is a page showing all proposed ideas for our application for the Google Summer of Code 2014.

About OpenKeychain

OpenKeychain is an OpenPGP implementation for Android. <img src="http://sufficientlysecure.org/wp-content/uploads/openpgp_device-613x1024.png" alt="Drawing" height="512" "width="306" align="right" /> It serves as a key management tool for encryption, decryption, signature generation, and signature verification. We are working together with K-9 Mail to provide email security according to the OpenPGP standard. It also allows encryption of files and provides an API for other developers to use. Thus, other Android applications will hopefully utilize this API in the future. While we are currently working on the API, there are several open tasks and improvements, which can be done for this project.

OpenKeychain can be installed from Google Play and F-Droid.

Features

  • OpenKeychain is Open Source and Free Software (GPLv3+) (-> verifiable cryptography)
  • All basic OpenPGP operations: encrypt/decrypt/sign/verify
  • NFC/QR code key exchange
  • Key management (import/export/sign/upload)
  • Import/export of GPG key rings and exported keys from/to the SD card
  • Basic keyserver support
  • Easy API

Prerequisites

  • Be a student enrolled at a university

Contribution Guidelines

  1. Join the development mailinglist at http://groups.google.com/d/forum/openpgp-keychain-dev
  2. Read the README, especially the notes about coding style
  3. Fork OpenKeychain and contribute code (the best part ;) )
  4. If you have questions ask on the mailinglist!
  5. Open a pull request on Github. I will help with occurring problems and merge your changes back into the main project.

I am happy about every code contribution and appreciate your effort to help us developing OpenKeychain!

"One patch" rule

We require one accepted patch (pull request) from each potential GSoC student, before accepting the student for GSoC participation.
The reason for this requirement is that you can show us that you have succeeded in building OpenKeychain, and that you have understood a little piece of OpenKeychain's code and are able to improve it. This requirement is based on the "two patches" rule applied by projects such as Inkscape and Subsurface.

I sorted out some probably easy issues and tagged them: https://github.com/openpgp-keychain/openpgp-keychain/issues?labels=simple-one-patch&page=1&state=open

Google Summer of Code Registration Procedure

  1. Have one patch accepted in OpenKeychain (see "one patch" rule)
  2. Lookout for interesting ideas on this page and choose multiple according to the time you expect to work on them. You can also propose your own ideas
  3. Tell us about your plans on the mailinglist
  4. Apply officially on the Google Summer of Code page (Registration opens on March 10, 2014, 7 p.m. UTC.)
  5. For accepted students participating in the Summer of Code, we encourage to open a blog and write about your progress.

Evaluation

(Shamelessly copied from Subsurface)
GSoC has two formal evaluation points, at the mid-term and at the end. These evaluations determine if you receive the stipend from Google. In order to receive a pass for the evaluations you will need to show adequate progress toward your project's goals.

To help you meet your goals and so that your mentor can better evaluate your progress you need to:

  • Have frequent, public discussions of your progress. (Don't rely on just your mentor for advice.)
  • Have a public OpenKeychain fork for your code to which you commit regularly.
  • Give weekly status reports for example via a blog.

For the final pass, you will normally be required to merge your code into OpenKeychain master.

Remember: we want you to succeed and we'd like you to stick around.

Ideas

Rewrite keyserver query backend

Brief explanation: The current implementation of the OpenPGP HTTP Keyserver Protocol (HKP) is based on parsing HTML output, resulting from a GET request. A better implementation should use machine readable output as specified by the Internet-Draft "The OpenPGP HTTP Keyserver Protocol (HKP)". No meaningful error messages are shown to the user. This should also be fixed according to the Internet-Draft. Additionally, a way to automatically switch to the next server if one is not reachable should be implemented. A new method for verification after looking up a key should conclude this task. If a specific fingerprint is requested, the downloaded key's fingerprint should be checked against the expected one (see https://github.com/openpgp-keychain/openpgp-keychain/issues/258).

Expected results: A revamped backend for keyserver queries.

Knowledge Prerequisite: Java programming

Skill level: low.

Mentor: Sergej Dechand

Contact: Mailinglist

Automatic contact discovery

Brief explanation: Currently, keys need to be downloaded manually by the user. This task could be improved by automatically discovering contacts by searching Android's contact database for emails and then downloading the corresponding keys from keyservers. This is difficult as many keys could be available to one email address, so a conflict resolution interface needs to be implemented. Some work also goes into the depth of Android's contact provider

Expected results: Automatic key download for Android contacts

Knowledge Prerequisite: Android and Java programming

Skill level: medium.

Mentor: Dominik Schürmann

Contact: Mailinglist or over XMPP (Jabber-ID: dominik@dominikschuermann.de)

Integration of OpenKeychain into Android's contact app

Brief explanation: So to speak, this is the other way around compared to the previous idea. For every key in OpenKeychain's database, there exist many user ids with email addresses. Those addresses can be mapped into the contact's database of Android by implementing a Contacts Provider Sync Adapter. If this is done correctly, a button inside Android's contact app could directly open a screen to encrypt something for this specific user. Eventually, this sync adapter needs to scan periodically or based on database changes inside OpenKeychain.

Expected results: Integration of OpenKeychain's keys into Android's contact app

Knowledge Prerequisite: Android and Java programming

Skill level: hard.

Mentor: Dominik Schürmann

Contact: Mailinglist or over XMPP (Jabber-ID: dominik@dominikschuermann.de)

Improvements to file encryption/decryption

Brief explanation: The idea in Android OS is to abstract away from a filesystem based model and go to a model where apps share content between each other. However, file managers were developed for the Android OS to manage files based on a filesystem level. Currently OpenKeychain requires an installed third-party file manager, like OI File Manager, to encrypt/decrypt files. This means it only supports URIs starting with file:// and no direct shared content. With Android 4.4 a new storage access framework was introduced making it even more important to allow other URIs than file://. In this task a new way to get shared content to encrypt/decrypt them should be developed. Instead of trying to parse URIs to get the absolute path to the file, content coming from all URIs should be cached, encrypted, and then the user can be asked into which file it should be saved.

Expected results: Replacement for the current file selection in encrypt/decrypt activities to support arbitrary URIs. Optionally, this could include the ability to select many files using Android 4.4's file picker.

Knowledge Prerequisite: Android and Java programming

Skill level: hard.

Mentor: Dominik Schürmann

Contact: Mailinglist or over XMPP (Jabber-ID: dominik@dominikschuermann.de)

Instrumentation Tests and Continuous Integration

Brief explanation: Automated tests would vastly improve the code quality by preventing regression bugs. By using Instrumentation Tests and Travis CI, an automated testing and build environment can be created. Android's developer docs and https://github.com/pestrada/android-tdd-playground contain some examples how to accomplish this. This task could optionally be extended to include testing of low level primitives like PgpSignEncrypt and PgpDecryptVerify classes.

Expected results: Automated tests and Continuous Integration for this project.

Knowledge Prerequisite: Android and Java programming

Skill level: hard.

Mentor: Dominik Schürmann

Contact: Mailinglist or over XMPP (Jabber-ID: dominik@dominikschuermann.de)

Incorporate "My Keys" into main contact list

<img src="http://openkeychain.org/new_list.jpeg" alt="Drawing" height="512" "width="306" align="right" /> Brief explanation: Android's contact application has a section at the beginning of the list, where your own contact is shown. We could use this pattern for OpenKeychain. Instead of having a list with sections "A", "B", "C" ... and contacts beginning with this character, we could introduce a section at the beginning named "My Keys", where your own private keys are listed. In addition to the normal view of the list's item, a button should be displayed on the right side named "Edit". This button should open the EditKeyActivity. A normal click should still open the ViewKeyActivity. Your own keys now should not appear again in the other sections. The result means that "My Keys" screen (SecretKeyListActivity) is no longer necessary.

Expected results: Key list like in Android's contact app. Removal of "My Keys" screen.

Knowledge Prerequisite: Android and Java programming

Skill level: hard.

Mentor: Dominik Schürmann

Contact: Mailinglist or over XMPP (Jabber-ID: dominik@dominikschuermann.de)

Trust Levels and Graphical Indication of Key Status

Brief explanation: It would be nice to inform the user if a key is verified or just downloaded from a keyserver by using a graphical indicator besides the key in every list. This could be similar to proprietary apps like Threema that indicate the "trust" status by color points. I like to encourage new design ideas. Before starting with this work make yourself familiar with the OpenPGP standard. It differentiates between valid certifications and trust (often people don't understand this). Currently OpenKeychain only implements certifications to a certain degree (no display).

Expected results: Design and implementation of trust indicators.

Knowledge Prerequisite: Android and Java programming

Skill level: medium.

Mentor: Dominik Schürmann

Contact: Mailinglist or over XMPP (Jabber-ID: dominik@dominikschuermann.de)

OpenPGP Certifications (also called key signatures)

Brief explanation: Currently OpenKeychain supports the certification of keys, but can't display them. The corresponding Fragment has already been added but is empty. Here a list should show all existing certifications. In OpenKeychain we like to save all information about keys in Android's SQLite database for easy and fast access via Content Providers. As this conflicts with the object-based model in the cryptography library Bouncy Castle, some helper methods are needed to solve this task. Eventually this idea could be executed together with the previous idea.

Expected results: Display of certifications

Knowledge Prerequisite: Android and Java programming

Skill level: medium.

Mentor: Dominik Schürmann

Contact: Mailinglist or over XMPP (Jabber-ID: dominik@dominikschuermann.de)

Improved design for tablets

Brief explanation: Currently OpenKeychain is mainly designed for smartphones. This could be vastly improved by several things. First, the navigation drawer could be made "always opened" for tablets to have the navigation on the left side. All activities working like "modal dialog" with buttons in the ActionBar could be made non-fullscreen. A more open question is how the encrypt and decrypt screens could be redesigned for a better experience on bigger screens.

Expected results: Optimized design for tablets

Knowledge Prerequisite: Android and Java programming

Skill level: medium.

Mentor: Dominik Schürmann

Contact: Mailinglist or over XMPP (Jabber-ID: dominik@dominikschuermann.de)

Website for openkeychain.org

Brief explanation: To make OpenKeychain more visible, a nicer website than the current one is needed. A modern fancy scroll-down website which displays nicely on mobile browsers should be designed and developed. I would prefer a static website which can then be hosted on Github Pages.

Expected results: Fancy website

Knowledge Prerequisite: HTML, CSS. Here the "one patch" rule does not apply, but you have to give references of previously designed websites to show your skills.

Skill level: medium.

Mentor: Dominik Schürmann

Contact: Mailinglist or over XMPP (Jabber-ID: dominik@dominikschuermann.de)