Mirrors
/
open-keychain
mirror of https://github.com/open-keychain/open-keychain.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Updated Google Summer of Code 2016 (markdown)

Vincent 2016-02-18 15:29:24 +01:00
parent 33bb5dcfa5
commit 7b7d1d1129
1 changed files with 107 additions and 74 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

181
Google-Summer-of-Code-2016.md

@ -54,14 +54,18 @@ This is a list of larger tasks which we have on our roadmap, and which we feel a
## Improved Key Search UI ## Improved Key Search UI
**Brief explanation:** The current dialog for search and import of keys is, **Brief explanation:** The current dialog for search and import of keys is,
compared to most of our other activities, quite outdated. Besides weaknesses in compared to most of our other activities, quite outdated. Besides weaknesses in
UI design, it is lacking a number of features, most notably display of UI design, it is lacking a number of features. However, these use cases are
information from the local database in addition to the data obtained from quite different from what the relevant code was originally designed for, so it
keyservers, and download and viewing of keys prior to actual import. However, should be rewritten in a more flexible way, to work with these new
these use cases are quite different from what the relevant code was originally requirements. The new UI should incorporate display of information from
designed for, which is why implementation of those new features will involve already known keys in addition to the data obtained from keyservers, and add an
some rewrites. option to download and view keys prior to actual import.
**Expected results:** Rewritten key search user interface and backend A secondary goal to this task is support for new key discovery options, notably
by lookup of OPENPGP records via DANE.
**Expected results:** Rewritten key search user interface and backend, key
discovery via DANE.
**Priority:** high **Priority:** high
@ -71,22 +75,26 @@ some rewrites.
**Mentor:** Vincent Breitmoser / Adithya Philip **Mentor:** Vincent Breitmoser / Adithya Philip
**Contact:** [Mailinglist](http://groups.google.com/d/forum/openpgp-keychain-dev) or over XMPP (Jabber-ID: dominik@dominikschuermann.de) **Contact:** [Mailinglist](https://lists.riseup.net/www/subscribe/openkeychain)
or on IRC (Valodim in [#openkeychain at
irc.freenode.net](https://kiwiirc.com/client/irc.freenode.net/openkeychain))
## Move from Passwords to App Lock Mechanism ## Move from Passwords to App Lock Mechanism
**Brief explanation:** At the moment, keys are individually encrypted with **Brief explanation:** At the moment, keys are encrypted individually with
their passphrases, prompting the user for the password before each use (with their passphrases, prompting the user for the password before each use (with
possible caching). This is mostly a historical design decision since it's what possible caching). This is mostly a historical design decision since it's what
GnuPG does. At this point however, we believe that most users are better served GnuPG does. At this point however, we believe that most users are better served
with a simple and easily understandable "app lock" mechanism. with a simple and easily understandable "app lock" mechanism.
Technically, this task involves moving the encryption of keys from the Technically, this task involves moving the mechanism which deals with
operations which work on them into the DataAccessObject. It also makes encryption of keys from the crypto operation classes into the DataAccessObject
re-encryption of secret keys during import necessary, making that an which is used to access the database. This makes it necessary to re-encrypt
interactive process. secret keys during import, which is not quite trivial to implement because it
requires user interaction during import.
**Expected results:** Individual passphrase mechanism is replaced by an "App Lock" one **Expected results:** Individual passphrase mechanism is replaced by an "App
Lock" one, keys are re-encrypted during import
**Priority:** high **Priority:** high
@ -96,7 +104,9 @@ interactive process.
**Mentor:** Vincent Breitmoser / Adithya Philip **Mentor:** Vincent Breitmoser / Adithya Philip
**Contact:** [Mailinglist](http://groups.google.com/d/forum/openpgp-keychain-dev) or over XMPP (Jabber-ID: dominik@dominikschuermann.de) **Contact:** [Mailinglist](https://lists.riseup.net/www/subscribe/openkeychain)
or on IRC (Valodim in [#openkeychain at
irc.freenode.net](https://kiwiirc.com/client/irc.freenode.net/openkeychain))
## Keyserver Sync Preference per Key ## Keyserver Sync Preference per Key
@ -122,7 +132,9 @@ sync with keyservers, and relevant behavior based on that preference.
**Mentor:** Vincent Breitmoser / Adithya Philip **Mentor:** Vincent Breitmoser / Adithya Philip
**Contact:** [Mailinglist](http://groups.google.com/d/forum/openpgp-keychain-dev) or over XMPP (Jabber-ID: dominik@dominikschuermann.de) **Contact:** [Mailinglist](https://lists.riseup.net/www/subscribe/openkeychain)
or on IRC (Valodim in [#openkeychain at
irc.freenode.net](https://kiwiirc.com/client/irc.freenode.net/openkeychain))
## TOFU Trust Model ## TOFU Trust Model
@ -133,11 +145,16 @@ of the concept](https://lists.gnupg.org/pipermail/gnupg-devel/2015-July/030150.h
on their mailing list. The general idea is to optimistically assume that a key on their mailing list. The general idea is to optimistically assume that a key
which is initially used to establish communication with any one communication which is initially used to establish communication with any one communication
partner is likely correct, and that if was no man in the middle attack happened partner is likely correct, and that if was no man in the middle attack happened
there, all further communication with the same key will be safe as well. To there, all further communication with the same key will be safe as well.
this end, a list of keys trusted in this way should be maintained, instances of
its use should be counted (how many e-mails did I encrypt to this key? how many To this end, a list of keys trusted in this way should be maintained, instances
signatures did I receive from it?), and an alarm raised if the same of its use should be counted (how many e-mails did I encrypt to this key? how
communication partner switches to a different key. many signatures did I receive from it?), and an alarm raised if the same
communication partner switches to a different key. This mechanism should
conceptually take interoperability with our current trust model into account
and provide an opt-out option for the user, and also take into consideration
how this affects the [public API](https://github.com/open-keychain/openpgp-api)
we expose for client apps.
**Expected results:** Support for a trust model based on the TOFU assumption **Expected results:** Support for a trust model based on the TOFU assumption
@ -149,89 +166,105 @@ communication partner switches to a different key.
**Mentor:** Vincent Breitmoser / Adithya Philip **Mentor:** Vincent Breitmoser / Adithya Philip
**Contact:** [Mailinglist](http://groups.google.com/d/forum/openpgp-keychain-dev) or over XMPP (Jabber-ID: dominik@dominikschuermann.de) **Contact:** [Mailinglist](https://lists.riseup.net/www/subscribe/openkeychain)
or on IRC (Valodim in [#openkeychain at
irc.freenode.net](https://kiwiirc.com/client/irc.freenode.net/openkeychain))
# Secondary Ideas ## Security Token Improvements
**Brief explanation:** OpenKeychain comes with support for security tokens
(YubiKey, Fidesmo Card, …), but there are some features missing in this area
for fully featured support.
This is a list of smaller tasks, which we expect to take one or two weeks at most. We encourage students to pick one of these along with their main task in their proposal, because after several weeks of working on one task it can be refreshing to just do something different for a while. The most important part of this task is creation of a nicer user interface for
importing the user's keys from a supplied token, improving the ui flow and
adding support for downloading the public key from a URL specified in the token
(see [here](https://github.com/open-keychain/open-keychain/issues/1587) for a
mockup). A smaller missing feature is editing the token's PIN.
A secondary goal of this task would be support for security tokens via OTG USB,
requiring some abstraction of the communication mechanism we use for NFC at the
moment from the [Nordpol](https://github.com/fidesmo/nordpol/) library.
## Detached Signatures A student who takes up this task should make sure to acquire testing equipment
**Brief explanation:** (ideally a Yubikey NEO) during the community bonding period (we might be able
to help get that hardware sponsored).
**Expected results:** **Expected results:** Redesigned Security Token import, PIN editing, USB-OTG support
**Priority:** **Priority:** medium
**Knowledge Prerequisite:** Java programming **Knowledge Prerequisite:** Java programming
**Skill level:** medium **Skill level:** medium
**Mentor:** Vincent Breitmoser / Adithya Philip **Mentor:** Vincent Breitmoser
**Contact:** [Mailinglist](http://groups.google.com/d/forum/openpgp-keychain-dev) or over XMPP (Jabber-ID: dominik@dominikschuermann.de) **Contact:** [Mailinglist](https://lists.riseup.net/www/subscribe/openkeychain)
or on IRC (Valodim in [#openkeychain at
irc.freenode.net](https://kiwiirc.com/client/irc.freenode.net/openkeychain))
## UI Integration Tests
**Brief explanation:**
**Expected results:**
**Priority:**
**Knowledge Prerequisite:** Java programming
**Skill level:** medium
**Mentor:** Vincent Breitmoser / Adithya Philip
**Contact:** [Mailinglist](http://groups.google.com/d/forum/openpgp-keychain-dev) or over XMPP (Jabber-ID: dominik@dominikschuermann.de)
## Deterministic Builds ## Deterministic Builds
**Brief explanation:** **Brief explanation:** Having deterministic, reproducible builds allows for
verifying F-Droid builds and thus using the same APK binaries on Google Play as
well as on F-Droid. This allows for easier upgrades and distributed
verifications that the published source code corresponds to the published APK
binary. Guardian Project has made [great progress towards a fully functional
solution](https://guardianproject.info/2015/02/11/complete-reproducible-app-distribution-achieved/).
In this task a Gradle plugin should be developed that allows us and other
projects to build deterministic builds without further dependencies on OS
programs or libs. Please read the related links for more information on how
this could be achieved.
**Expected results:** Related links:
* http://imperceptiblethoughts.com/2013/12/20/reproducible-multi-project-gradle-builds-part-2.html
* https://wiki.debian.org/ReproducibleBuilds/TimestampsInJarFiles
* http://code.briarproject.org/akwizgran/sortjar
**Priority:** This is a smaller task which we expect to take only one or two weeks, which
makes it suitable as a secondary goal and providing a change of pace for some
time while working on another task.
**Expected results:** Analysis of non-deterministic parts in the build process,
gradle plugin for deterministic builds
**Priority:** low
**Knowledge Prerequisite:** Java programming **Knowledge Prerequisite:** Java programming
**Skill level:** medium **Skill level:** medium
**Mentor:** Vincent Breitmoser / Adithya Philip **Mentor:** Vincent Breitmoser
**Contact:** [Mailinglist](http://groups.google.com/d/forum/openpgp-keychain-dev) or over XMPP (Jabber-ID: dominik@dominikschuermann.de) **Contact:** [Mailinglist](https://lists.riseup.net/www/subscribe/openkeychain)
or on IRC (Valodim in [#openkeychain at
irc.freenode.net](https://kiwiirc.com/client/irc.freenode.net/openkeychain))
## Support Yubikey PIN Change ## Detached Signatures
**Brief explanation:** **Brief explanation:** In our current UI, we do not support verification of
files which are signed with a detached signature. The reason for this is that
it does not easily fit into our current user interface patterns, in addition to
a slightly more limited prevalence of this use case on Android compared to
other systems. For the sake of feature completeness however, this would be nice
to have, and might work nicely as a "warm-up" task.
**Expected results:** This is a smaller task which we expect to take only one or two weeks, which
makes it suitable as a secondary goal and providing a change of pace for some
time while working on another task.
**Priority:** **Expected results:** Support for detached signatures in the Encrypt/Decrypt
dialog.
**Priority:** low
**Knowledge Prerequisite:** Java programming **Knowledge Prerequisite:** Java programming
**Skill level:** medium **Skill level:** low
**Mentor:** Vincent Breitmoser / Adithya Philip **Mentor:** Vincent Breitmoser
**Contact:** [Mailinglist](http://groups.google.com/d/forum/openpgp-keychain-dev) or over XMPP (Jabber-ID: dominik@dominikschuermann.de) **Contact:** [Mailinglist](https://lists.riseup.net/www/subscribe/openkeychain)
or on IRC (Valodim in [#openkeychain at
irc.freenode.net](https://kiwiirc.com/client/irc.freenode.net/openkeychain))
## Improved Yubikey Import
**Brief explanation:**
**Expected results:**
**Priority:**
**Knowledge Prerequisite:** Java programming
**Skill level:** medium
**Mentor:** Vincent Breitmoser / Adithya Philip
**Contact:** [Mailinglist](http://groups.google.com/d/forum/openpgp-keychain-dev) or over XMPP (Jabber-ID: dominik@dominikschuermann.de)