aboutsummaryrefslogtreecommitdiff
path: root/README
blob: 89fdf8d614609622bcae5a78afb204e6ca9cd173 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
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