aboutsummaryrefslogtreecommitdiff
path: root/README
diff options
context:
space:
mode:
authorrhatto <rhatto>2005-06-23 01:24:05 +0000
committerrhatto <rhatto>2005-06-23 01:24:05 +0000
commit5a7e904d0a405da51834ba606545d0f58b806304 (patch)
treef5fa83f7588eb6961fc71700985e1408c42a6eac /README
parent3d49948fce1260171c9e7b4ef805f01885c370af (diff)
downloadfirma-5a7e904d0a405da51834ba606545d0f58b806304.tar.gz
firma-5a7e904d0a405da51834ba606545d0f58b806304.tar.bz2
added COPYING and README
Diffstat (limited to 'README')
-rwxr-xr-xREADME153
1 files changed, 153 insertions, 0 deletions
diff --git a/README b/README
new file mode 100755
index 0000000..89fdf8d
--- /dev/null
+++ b/README
@@ -0,0 +1,153 @@
+
+ ffff
+ ff firma -
+ ffff encrypted mailing list manager
+ ff - a firma cai mas nao quebra
+ ff
+
+The concept
+-----------
+
+ In portuguese, "firma" means for signature, signature and trust checking and
+ is a slang for strenght and enteprise.
+
+ All this together just can be one thing: an encrypted mailing list manager :P
+
+ In the streets, the expression "a firma cai mas nao quebra" (the enterprise
+ falls but does not breaks) is commonly used to talk about the strenght of a
+ group that operates in secrecy. To our list manager, this concept says that
+ your encrypted mailing list can stops to work -- if the server goes offline
+ or abducted by aliens -- but the system can never be broken. With firma, we
+ are trying to follow this philosophy.
+
+ Firma is based on the gpgmailalias.pl perl script, hosted at
+ http://www.rediris.es/app/pgplist/index.en.html, but completely rewritten
+ in bash.
+
+ Firma works as a command line and MTA pipe alias tool that receives a
+ email message in its input, grab the encrypted and signed message and
+ re-encrypt and send it to each subscriber.
+
+ In the server you just need the script, a keyring with the list keypair
+ and a config file. When mail arrives, it is redirected by the MTA to the
+ script and it process the message if its properly encrypted and signed.
+ No temporary 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
+-------------------------------------------------------------
+
+ 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 consider the case where every subscribers encrypt
+ the message to all recipients cause...
+
+ For the second option we have the NAH6 Mailman patch,
+ http://mail.python.org/pipermail/mailman-coders/2003-June/000506.html
+
+ For the first we have GPG Mailman,
+ http://medien.informatik.uni-ulm.de/~stefan/gpg-mailman.xhtml
+
+ This is a question of centralized versus descentralized vulnerability.
+
+ - descentralized means just an alias for incoming encrypted email
+
+ - if some user has its keypair compromissed, the list admin just need
+ to remove the correspondent pubkey from the list's keyring
+
+Why Bash
+--------
+
+ You may ask why we choosed bash. Its really strange a crypto project using
+ shell scripting language. But bash has many advantages:
+
+ - Bash is found in almost all unix-like systems
+
+ - Small dependencies: firma needs just tools like sed, awk, grep, cut and
+ gpg itself
+
+ - You can easily put all the tools, scripts and config files in a read-only
+ media to protect againt cracks such as rootkits.
+
+ - Keeping your encripted list manager out from a huge and sometimes bugged
+ mail software ...
+
+Setup
+-----
+
+ Firma installation is quite simple:
+
+ 1 - create a folder to store lists; by default firma use /usr/local/etc/lists
+ but you can use anything, just edit firma and change FIRMA_LIST_PATH
+ variable.
+
+ 2 - copy firma script to whatever you like, eg. /usr/local/bin and check that
+ it has no write permission
+
+ 3 - then create your lists with the command
+
+ firma -c your-list
+
+ this will ask some questions and create a gpg keyring and a config file
+ with the following variables:
+
+ MAIL= path for mail program (eg, /usr/bin/nail)
+ GPG= path for gnupg binary (eg, /usr/bin/gpg)
+ LISTNAME= list email (eg, firma@domain.tld)
+ LISTADMIN= list administrator email addresses (space separated)
+ GPGDIR= gpg dir for the lists' keyring
+ PASSWD= passwd for the lists' keyring
+
+ the owner of the config file and keyring is nobody.nobody and its
+ permissions are 600.
+
+ 4 - create an alias to the list at your MTA; on sendmail or postfix,
+ add this to your aliases file:
+
+ your-list: "| /usr/local/bin/firma -p your-list"
+ your-list-request: "| /usr/local/bin/firma -r your-list"
+
+ and then run the command
+
+ newaliases
+
+ 5 - to subscribe the users and the list admins on the list, use ...
+
+Tips
+----
+
+ - Use an encrypted swap memory
+ - Use a read-only media to store ...
+ - Use ramdisk to the ...
+ - Use a big PASSWD, 25+ chars with alpha-numeric and special ascii keys
+
+Design and features
+-------------------
+
+ Firma is simple but its simplicity does'nt reflect in lack of design.
+
+ - uses a gpg keyring to store both the keys and the subscribers options
+
+ - command line is simple to avoid admin tasks resting in some .bash_history
+
+ - non-pgp blocks in a message are discarded since we dont want to deal with
+ unencrypted content
+
+ - all unwanted email headers are striped as a privacy measure for who sends
+ the message
+
+ - firma does'nt use any disk write when processing a message; no temp files
+ that may rest in the system; everything goes in memory (but take care,
+ sometimes it will use the swap and then is best to make it encrypted)
+
+ - by default it doesn't archive messages in the server
+
+ - by default it remove the Subject header and put it inside the encrypted
+ message, as Subject are outside the PGP/MIME context
+
+ Major features are:
+
+ - keyring support
+
+ - administration through email