diff options
| author | Silvio Rhatto <rhatto@riseup.net> | 2013-05-09 22:42:44 -0300 |
|---|---|---|
| committer | Silvio Rhatto <rhatto@riseup.net> | 2013-05-09 22:42:44 -0300 |
| commit | cf4b4e642cd8493a6185ec31c58a787491366905 (patch) | |
| tree | d03f90d7a5bb020203d2b619012301d5f175bce5 | |
| parent | 17c23f2084eb3f9af51f5d6537d6a514861f7bdd (diff) | |
| download | firma-cf4b4e642cd8493a6185ec31c58a787491366905.tar.gz firma-cf4b4e642cd8493a6185ec31c58a787491366905.tar.bz2 | |
Formatting and development note
| -rw-r--r-- | index.mdwn | 19 |
1 files changed, 11 insertions, 8 deletions
@@ -6,6 +6,9 @@ * [License](COPYING): GNU GPL v2 * [Guidelines](GUIDELINES) +*NOTE:* Firma development is currently on hold, but patches and pull requests are still +accepted. Please check [schleuder](http://schleuder2.nadir.org) for an alternative. + Getting the code ---------------- @@ -28,8 +31,8 @@ files are written during a message processing and no default message archive, so no messages -- encrypted or not -- rest on your system in all steps of the process. -Everyone has the private key X The server has the private key -------------------------------------------------------------- +Architecture +------------ When using a encrypted mailing list software, one must choose between keeping the private key in the server or send it to each of the subscribers. We'll not @@ -66,14 +69,14 @@ These two approaches has a similar external hole of some private key turned public. Designing Firma, we decided for the centralized model, for three main reasons: -1 - A server can be safer than any user's ordinary computer. +1. A server can be safer than any user's ordinary computer. -2 - Automation: when some user is removed from the list, we just remove their -key from the list keyring; in the decentralized approach, the list admin needs -to regenerate a new list keypair, otherwise the unsubscribed user can still -decrypt list messages if he can sniff the mail server traffic. +2. Automation: when some user is removed from the list, we just remove their + key from the list keyring; in the decentralized approach, the list admin needs + to regenerate a new list keypair, otherwise the unsubscribed user can still + decrypt list messages if he can sniff the mail server traffic. -3 - Use a public-key and all info stored onto it as the subscriber info. +3. Use a public-key and all info stored onto it as the subscriber info. Why Bash -------- |