The concept
-----------
- In portuguese, "firma" means for signature, signature and trust checking and
- is a slang for strength and enterprise.
+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.
- All this together just can be one thing: an encrypted mailing list manager :P
+Firma works as a command line and MTA pipe alias tool that receives an email
+message in its input, grab the encrypted/signed message, re-encrypt and send it
+to each subscriber.
- 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 strength 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 an
- email message in its input, grab the encrypted/signed message, re-encrypt
- and send it to each subscriber.
-
- In the server you just need the script, a keyring with the list keypair
- and two config files. 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.
+In the server you just need the script, a keyring with the list keypair and two
+config files. 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 this has none automation in the
- process we are looking for.
-
- For the first there are some options:
-
- - Schleuder
- http://schleuder2.nadir.org/
-
- - GPG Mailman
- http://medien.informatik.uni-ulm.de/~stefan/gpg-mailman.xhtml
+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 this has none automation in the process we are looking for.
- - Crypt-ML - gpg-ezmlm
- http://www.synacklabs.net/projects/crypt-ml/
+For the first there are some options:
- - Secure Email List Services (SELS)
- http://sels.ncsa.illinois.edu/
+- Schleuder: http://schleuder2.nadir.org/
+- GPG Mailman: http://medien.informatik.uni-ulm.de/~stefan/gpg-mailman.xhtml
+- Crypt-ML - gpg-ezmlm: http://www.synacklabs.net/projects/crypt-ml/
+- Secure Email List Services (SELS): http://sels.ncsa.illinois.edu/
- For the second option there is the NAH6 Mailman patch,
- http://mail.python.org/pipermail/mailman-coders/2003-June/000506.html
+For the second option there is the NAH6 Mailman patch,
+http://mail.python.org/pipermail/mailman-coders/2003-June/000506.html
- For the firsts releases of Firma, we choose to use just the first option.
- In the future the code should contain support for an one-keypair list,
- but this is not the main behavior we want in an encrypted mailing list.
- This is a question of centralized versus decentralized vulnerability.
+For the firsts releases of Firma, we choose to use just the first option.
+In the future the code should contain support for an one-keypair list,
+but this is not the main behavior we want in an encrypted mailing list.
+This is a question of centralized versus decentralized vulnerability.
- An one-keypair list is more or less just like a mail alias: someone
- send an encrypted email to the list address and the manager just forwards
- that encrypted email to the lists subscribers, optionally removing some
- headers and performing some security auditing. Every user has the list
- private key, so if someone lost it to the world then one must regenerate
- a keypair and send again to every subscriber.
+An one-keypair list is more or less just like a mail alias: someone
+send an encrypted email to the list address and the manager just forwards
+that encrypted email to the lists subscribers, optionally removing some
+headers and performing some security auditing. Every user has the list
+private key, so if someone lost it to the world then one must regenerate
+a keypair and send again to every subscriber.
- In the case of a keypair stored in the server, where subscribers has just
- the list pubkey, the list admin just need to remove the correspondent pubkey
- from the list's keyring with in case some user has its keypair compromised.
+In the case of a keypair stored in the server, where subscribers has just
+the list pubkey, the list admin just need to remove the correspondent pubkey
+from the list's keyring with in case some user has its keypair compromised.
- 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:
+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
--------
- You may ask why we choose bash. Its really strange a crypto project using
- shell scripting language. But bash has many advantages:
+You may ask why we choose 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
+- Bash is found in almost all unix-like systems
- - Small dependencies: firma needs just tools like sed, awk, grep, cut and
- gpg itself. Look at the file "GUIDELINES" to see a complete list of all
- unix commands needed to run firma.
+- Small dependencies: firma needs just tools like sed, awk, grep, cut and
+ gpg itself. Look at the file "GUIDELINES" to see a complete list of all
+ unix commands needed to run firma.
- - You can easily put all the tools, scripts and config files in a read-only
- media to protect against cracks such as rootkits.
+- You can easily put all the tools, scripts and config files in a read-only
+ media to protect against cracks such as rootkits.
- - Keeping your encrypted list manager out from a huge and sometimes bugged
- mail software prevents insecure use of your mailing list by an excess of
- unwanted functions and routines.
+- Keeping your encrypted list manager out from a huge and sometimes bugged
+ mail software prevents insecure use of your mailing list by an excess of
+ unwanted functions and routines.
- - Firma has a total KISS design, and bash helps to keep it simple.
+- Firma has a total KISS design, and bash helps to keep it simple.
- - Firma adopted the style suggested in the Advanced Bash-Scripting Guide,
- http://www.tldp.org/LDP/abs/html/scrstyle.html
+- Firma adopted the style suggested in the Advanced Bash-Scripting Guide,
+ http://www.tldp.org/LDP/abs/html/scrstyle.html
Development Guidelines
----------------------
- As a security project we made a restricted set of guidelines / design policy,
- attempting to get a clean, bug-free and high quality code. We choose a slow
- development rather than sit-and-code. These rules are detailed in the file
- GUIDELINES.
+As a security project we made a restricted set of guidelines / design policy,
+attempting to get a clean, bug-free and high quality code. We choose a slow
+development rather than sit-and-code. These rules are detailed in the file
+[[GUIDELINES]].
Setup
-----
- Note for Debian users: you'll need the "expect" package to run firma.
+Note for Debian users: you'll need the "expect" package to run firma.
- Firma installation is quite simple:
+Firma installation is quite simple:
- 1 - Create a folder to store lists; by default firma use /var/lib/firma/lists
- but you can use anything, just edit firma and change FIRMA_LIST_PATH
- variable.
+1. Create a folder to store lists; by default firma use /var/lib/firma/lists
+ but you can use anything, just edit firma and change FIRMA_LIST_PATH
+ variable.
- 2 - Copy firma script to whatever you like, e.g. /usr/local/bin and check that
- it has no write permission
+2. Copy firma script to whatever you like, e.g. /usr/local/bin and check that
+ it has no write permission
- 3 - Create a list-wide config file (default is /var/lib/firma/firma.conf) with
- the common definitions for all lists. You might just copy the sample
- firma.conf.dist and edit according to your needs.
+3. Create a list-wide config file (default is /var/lib/firma/firma.conf) with
+ the common definitions for all lists. You might just copy the sample
+ firma.conf.dist and edit according to your needs.
All config variables can be overwritten at each list's own config file;
firma.conf should be chmoded as 600, chowned nobody.nobody or whatever
firma --help config
- 4 - Then create your lists with the command
+4. Then create your lists with the command
firma -c your-list
- Then firma will ask some questions and create a gpg keyring and a config
- file with the following variables:
+Firma will ask some questions and create a gpg keyring and a config file with
+the following variables:
LIST_ADDRESS= list's email address
LIST_ADMIN= list's administrators email addresses (space separated)
LIST_HOMEDIR= list's GnuPG homedir, where the list's keyrings are located
PASSPHRASE= passphrase for the list's private keyring
- Then a gpg keypair and a config file are automatically generated;
- the owner of the config file and keyring should be nobody.nobody
- (or the user your MTA run as) and its permissions must be 600.
+A gpg keypair and a config file are automatically generated; the owner of the
+config file and keyring should be nobody.nobody (or the user your MTA run as)
+and its permissions must be 600.
- After that you can add some optional parameters on this list config file:
+After that you can add some optional parameters on this list config file:
SUBJECT_PREFIX= prefix to be included in the subject of list messages
firma --help config
- 5 - Create an alias to the list at your MTA; on sendmail or postfix,
- add this to your aliases file:
+6. 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 -e your-list"
alternatively, you can use a virtual mailbox table if you want
to easily host a lot of encrypted mailing lists.
- 6 - Admin tasks are performed through aliases like your-list-request@yourmachine
- or via command-line:
+7. Admin tasks are performed through aliases like your-list-request@yourmachine
+ or via command-line:
firma -a your-list
- inside this command or encrypted in your mailing list request, use the
- following commands:
+Inside this command or encrypted in your mailing list request, use the
+following commands:
sub keyserver|keyfile key-id
uses the given address for message delivery instead
of the primary address of a subscribed key
- 7 - To subscribe and unsubscribe manually the users and the list admins on, use
- a command line like
+8. To subscribe and unsubscribe manually the users and the list admins on, use
+ a command line like
gpg --homedir [path-to-your-list-keyring] --import < file
and be sure that after this command the list keyring is owned by nobody.nobody.
- 8 - Send encrypted AND signed messages to your-list@yourmachine and look
- what happens :)
+9. Send encrypted AND signed messages to your-list@yourmachine and look
+ what happens :)
Tips
----
- - Use an encrypted swap memory
- - Use a read-only media to store firma and its needed apps
- - Use ramdisk to FIRMA_LIST_PATH so all keys and passwords vanishes if the server is shutdown
- - Use a big PASSPHRASE, 25+ chars with alpha-numeric and special ascii keys
+- Use an encrypted swap memory
+- Use a read-only media to store firma and its needed apps
+- Use ramdisk to FIRMA_LIST_PATH so all keys and passwords vanishes if the server is shutdown
+- Use a big PASSPHRASE, 25+ chars with alpha-numeric and special ascii keys
Design and features (OUTDATED)
--------------------
+------------------------------
- Firma is simple but its simplicity doesn't reflect in lack of design.
+Firma is simple but its simplicity doesn't reflect in lack of design.
- - Uses a gpg keyring to store both the keys and the subscribers options
+- 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
+- Command line is simple to avoid admin tasks resting in some .bash_history
- - Non-pgp blocks in a message are discarded since we don't want to deal with
- unencrypted content
+- Non-pgp blocks in a message are discarded since we don't want to deal with
+ unencrypted content
- - All unwanted email headers are striped as a privacy measure for who sends
- the message
+- All unwanted email headers are striped as a privacy measure for who sends
+ the message
- - Firma doesn't 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)
+- Firma doesn't 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 doesn't archive messages in the server
- - By default it removes the Subject header and put it inside the encrypted
- message, as Subject are outside the PGP/MIME context
+- By default it removes the Subject header and put it inside the encrypted
+ message, as Subject are outside the PGP/MIME context
- - Messages appear to be sent To: Undisclosed Recipients
+- Messages appear to be sent To: Undisclosed Recipients
- Major features are:
+Major features are:
- - Keyring support
+- Keyring support
- - Administration through email or command-line
+- Administration through email or command-line
-8 - Caveats
+Caveats
+-------
- People that uses Sylpheed should config the list to accept messages that
- arent signed. Thats because currently firma depends that the encrypted
- and signed parts come in the same PGP block and Sylpheed splits the
- encrypted message and the signature in two separate blocks. Thats a
- firma and not Sylpheed issue. The PGP/MIME spec allows one to send
- the PGP/MIME encrypted message in two separate blocks. We hope to fix
- this someday :)
+People that uses Sylpheed should config the list to accept messages that arent
+signed. Thats because currently firma depends that the encrypted and signed
+parts come in the same PGP block and Sylpheed splits the encrypted message and
+the signature in two separate blocks. Thats a firma and not Sylpheed issue. The
+PGP/MIME spec allows one to send the PGP/MIME encrypted message in two separate
+blocks. We hope to fix this someday :)
-9 - Contact
+Contact
+-------
- Contact: firma (@) firma.sarava.org
+Contact: firma (@) firma.sarava.org
- Messages should be encrypted with the list pubkey
- 3DF104314023E18358EFDD270D51B4E79E693CF7 found at keys.indymedia.org.
+Messages should be encrypted with the list pubkey
+`3DF104314023E18358EFDD270D51B4E79E693CF7` found at keys.indymedia.org.
projects / firma.git / commitdiff