Updated Google Summer of Code 2016 (markdown)
Vincent
parent
33bb5dcfa5
commit
7b7d1d1129
|
|
@ -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
|
||||
**Brief explanation:** The current dialog for search and import of keys is,
|
||||
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
|
||||
information from the local database in addition to the data obtained from
|
||||
keyservers, and download and viewing of keys prior to actual import. However,
|
||||
these use cases are quite different from what the relevant code was originally
|
||||
designed for, which is why implementation of those new features will involve
|
||||
some rewrites.
|
||||
UI design, it is lacking a number of features. However, these use cases are
|
||||
quite different from what the relevant code was originally designed for, so it
|
||||
should be rewritten in a more flexible way, to work with these new
|
||||
requirements. The new UI should incorporate display of information from
|
||||
already known keys in addition to the data obtained from keyservers, and add an
|
||||
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
|
||||
|
||||
|
|
@ -71,22 +75,26 @@ some rewrites.
|
|||
|
||||
**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
|
||||
**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
|
||||
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
|
||||
with a simple and easily understandable "app lock" mechanism.
|
||||
|
||||
Technically, this task involves moving the encryption of keys from the
|
||||
operations which work on them into the DataAccessObject. It also makes
|
||||
re-encryption of secret keys during import necessary, making that an
|
||||
interactive process.
|
||||
Technically, this task involves moving the mechanism which deals with
|
||||
encryption of keys from the crypto operation classes into the DataAccessObject
|
||||
which is used to access the database. This makes it necessary to re-encrypt
|
||||
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
|
||||
|
||||
|
|
@ -96,7 +104,9 @@ interactive process.
|
|||
|
||||
**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
|
||||
|
|
@ -122,7 +132,9 @@ sync with keyservers, and relevant behavior based on that preference.
|
|||
|
||||
**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
|
||||
|
|
@ -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
|
||||
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
|
||||
there, all further communication with the same key will be safe as well. To
|
||||
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
|
||||
signatures did I receive from it?), and an alarm raised if the same
|
||||
communication partner switches to a different key.
|
||||
there, all further communication with the same key will be safe as well.
|
||||
|
||||
To 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 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
|
||||
|
||||
|
|
@ -149,89 +166,105 @@ communication partner switches to a different key.
|
|||
|
||||
**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
|
||||
**Brief explanation:**
|
||||
A student who takes up this task should make sure to acquire testing equipment
|
||||
(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
|
||||
|
||||
**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)
|
||||
|
||||
|
||||
## 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)
|
||||
**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))
|
||||
|
||||
|
||||
## 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
|
||||
|
||||
**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
|
||||
**Brief explanation:**
|
||||
## Detached Signatures
|
||||
**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
|
||||
|
||||
**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)
|
||||
|
||||
|
||||
## 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)
|
||||
**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))
|
||||
|
|
|
|||
Loading…
Reference in New Issue