diff options
| -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 -------- |