summaryrefslogtreecommitdiff
path: root/README
diff options
context:
space:
mode:
authorSilvio Rhatto <rhatto@riseup.net>2009-11-01 10:57:38 -0200
committerSilvio Rhatto <rhatto@riseup.net>2009-11-01 10:57:38 -0200
commit036440ef1aa2828b574d6436e594b9e40af0d813 (patch)
treee41e071a236e192fb333abe7442deca79fd51840 /README
parent199c31205f9a25f99a87017a6732e7afa664723b (diff)
downloadkeyringer-036440ef1aa2828b574d6436e594b9e40af0d813.tar.gz
keyringer-036440ef1aa2828b574d6436e594b9e40af0d813.tar.bz2
Adding 'Concepts' section on README
Diffstat (limited to 'README')
-rw-r--r--README57
1 files changed, 56 insertions, 1 deletions
diff --git a/README b/README
index c1768be..40ec823 100644
--- a/README
+++ b/README
@@ -38,8 +38,57 @@ Exporting private keys (take care):
gpg --armor --export-secret-keys
+Concepts
+--------
+
+Basic idea is:
+
+ - Encrypt stuff with ppl's gpg pubkeys and push the output
+ in a git repo.
+
+ - Let ppl keep it in sync with the repo and the keys are
+ shared :)
+
+For "key" it's meant anything as the script work with stdin and output things to
+files, so it can be passphrases, private keys or other kind of info.
+
+It's possible to share keys using an encrypted mailing list, but the main
+difficulty is to track the message where the keys are.
+
+With theses scripts, the workflow is more or less like this:
+
+ - You have a git repo for secret keys.
+
+ - You run the "encrypt" command and paste your private key to this
+ command (so no plaintext disk write).
+
+ - The encrypt command writes an encrypted file to the repo.
+
+ - You manually add it to git and push it to remote repositories.
+
+ - Optionally, other ppl pulls the changes but they dont need to
+ decrypt anything until they need to use the keys.
+
+So it's just gpg-encrypted data atop of a git repository (one can think of a
+kind of distributed encrypted filesystem).
+
+Git was chosen to host encrypted info mostly for two reasos: easy to distribute
+and its the only VCS known to make easier repository history manipulation.
+
+One possible drawback: the repo has pubkey information attached, which can be
+linked to real ppl (and then disclose the information about who has access to a
+given key), but it's possible to:
+
+ - Keep the repo just atop of an encrypted and non-public place.
+
+ - Or to consider an integration with gpg's --hidden-recipient option.
+
TODO
-====
+----
+
+Currently the script just handle encrypt/decrypt of files but no automatic git
+operation (which needs to be managed by hand). There are lots of things that
+can be enhanced:
- Enhanced documentation.
- Better intregation with gpg.
@@ -53,4 +102,10 @@ TODO
- Automatic repository maintenance functions.
- Hooks to inform users.
- Removal of old history.
+
+Development
+-----------
+Currently there are have no solid plans to package these scripts but it might
+be possible instead to integrate the scripts and the keys using git's submodule
+feature.