aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorDominik Schürmann <dominik@dominikschuermann.de>2014-08-07 09:29:01 +0200
committerDominik Schürmann <dominik@dominikschuermann.de>2014-08-07 09:29:01 +0200
commit4934c25feadffb5402d23e56c9cc9d5ddcaa39c0 (patch)
treea823e4868810b732cd0b1aa92f7a6dc59d39e752
parentbac767d184b9120a251330242a79ed363ad854fc (diff)
downloadopen-keychain-4934c25feadffb5402d23e56c9cc9d5ddcaa39c0.tar.gz
open-keychain-4934c25feadffb5402d23e56c9cc9d5ddcaa39c0.tar.bz2
open-keychain-4934c25feadffb5402d23e56c9cc9d5ddcaa39c0.zip
Move design doc into wiki
-rw-r--r--DESIGN.mkd55
1 files changed, 0 insertions, 55 deletions
diff --git a/DESIGN.mkd b/DESIGN.mkd
deleted file mode 100644
index 342f567a9..000000000
--- a/DESIGN.mkd
+++ /dev/null
@@ -1,55 +0,0 @@
-# Design Notes on Open-Keychain
-
-This document contains notes on the software design of open keychain. Points
-with a * are yet to be implemented.
-
-
-## Database design
-
-The database has two distinct types of tables:
-- The key\_ring\_{public,secret} tables, which hold binary blobs of all known
- public and private keys, respectively, and nothing else.
-- All other tables, which cache information about key rings in a consistent
- manner. This information includes various pieces of metadata about each key's
- subkeys, user ids, and certificates.
-
-### Constraints
-
-All tables in the database have FOREIGN KEY constraints related to the
-key\_ring\_public table. This is also true for the key\_ring\_secret table,
-which means that secret keys cannot exist in the database without their public
-key counterparts. This has implications in particular on the order of insertion
-for private key rings and their public key ring counterparts into the database,
-even more so when editing a key ring is edited.
-
-### Cache usage considerations
-
-It is of note that extraction of metadata from key rings is in some cases a
-surprisingly expensive operation. As a prime example (heh), properly extracting
-a key's associated primary user id requires examination and possibly
-verification of all self-certificates, which in turn requires examination of
-all certificates.
-
-To ensure consistency, each type of metadata must be extracted one way in
-exactly one routine. For this reason, it is often desirable to make use of
-cached data even when the underlying pgp key ring objects are contextually
-available.
-
-
-## Further work / WIP
-
-### Separation of concerns
-
-Roughly speaking, the crypto code should be strictly separated from the android
-code. At the time of this writing (30.04.14), most of these thoughts are yet to
-be put into practice.
-
-There are three aspects to OK which should be kept largely separate:
-- Firstly, there is Code dealing with pgp and crypto. This code exclusively makes
- use of the BouncyCastle library. It lives in the .pgp package.
-- Secondly, there is code dealing with user interface and system integration,
- which makes exclusive use of Android classes.
-- Between these, there is glue code that is responsible for mapping pgp objects
- to the database, and calling methods provided by the crypto code from the ui
- code.
-