Mentre Grillo si radicalizza sempre di piu', come previsto, vorrei dire due parole su questo piccolo pezzo di codice che sta venendo scaricato con una certa attenzione , crescente.Ho accennato a questo software che mi sono messo a scrivere - pur non essendo uno sviluppatore - ma non ho mai spiegato bene cosa io mi proponga di fare, perche' e per chi. Essenzialmente ho scritto quel software quando mi sono chiesto cosa impedisse che, almeno in teoria , qualcuno entri nella mia email (o in quella di mia moglie) e ci tiri fuori tutto mettendolo in pubblico.
Forse voi tutti conoscete GPG (la versione GPL di PGP): se entrambi i capi della comunicazione via email hanno installato GPG e un software come Enigmail, che permette a Thunderbird di usarlo con facilita', e' possibile criptare il corpo delle mail in modo da renderlo illeggibile da chiunque non abbia le chiavi private dei due capi.
Le versioni 1.0.X
La prima implementazione realizzava lo use case standard, avendo in mente gli RFC e assumendo the tutti li rispettassero. Sembrava funzionare bene, ma poi ho deciso di fare un pochino di QA+ test automation.
Il blueprint completo per la 2.0 e' quindi:
- Adesso che l'algoritmo e' robusto, Trasformate GPG-Body in un vero codice ad oggetti.
- Gestire la trasformazione del messaggio con una macchina a stati deterministica, in modo da poter aggiungere stati (ovvero funzionalita').
- Unendo le due cose, ottenere un sistema transazionale, ove se qualcosa va storto si ritorna allo stato iniziale.
Quando diffondevo gpg-body solo mediante una tarball, esso veniva scaricato da sysadmin capaci di scaricarla e compilarla e installarla. Non ho avuto particolari problemi con loro, se non le segnalazioni di problemi (i bachi di cui parlo sopra).
Alcuni hanno notato che se passano solo il recipient a gpg quando lo usano dentro un MTA , non funzioni se si usano virtual users. Certo che no. Essendo invocato dall' MTA, esso gira con un utente assegnato dall' MTA stesso: se non esiste un sottostante utente locale, gpg non sapra' dove prendere le chiavi. In quel caso, o usate un keyserver oppure usare le opzioni
--keyring file e --options file .
Dovete pero' capire che diavolo stiate facendo: nella documentazione ho scritto chiaramente che ogni parametro passiate a gpg-body finira' in pasto a gpg (tranne -o e --output , perche' lasciar redirigere l'output di un oggetto che diventa root quando mandate email a root non mi piace proprio) . Se ho scritto questo nella documentazione, e le cose stanno cosi', dovrete proprio sapere che diavolo passate al comando.
L'approccio "fai apt-get install qualcosa e funziona tutto, non devi capire" e' un approccio del cazzo. Non posso accusare Ubuntu di questo perche' Ubuntu non vieta a nessuno di studiare , ma esso si e' diffuso troppo tra i sysadmin.
La mia posizione e' che siete dei sysadmin: o capite quel che fate, o vi ficcate le manine altrove.
L'approccio "fai apt-get install qualcosa e funziona tutto, non devi capire" e' un approccio del cazzo. Non posso accusare Ubuntu di questo perche' Ubuntu non vieta a nessuno di studiare , ma esso si e' diffuso troppo tra i sysadmin.
La mia posizione e' che siete dei sysadmin: o capite quel che fate, o vi ficcate le manine altrove.
Un altro punto e' che gpg-body scrive in /tmp
Si, lo fa. Ma ci scrive solo roba criptata da gpg, e la cancella subito dopo, quindi i files durano pochi millisecondi. Su un server avrete molta RAM, e quella che non usate viene usata (in Linux e in molti Unix) come cache per il filesystem, quindi non vi rallenta. Ma avere in ram SIA il messaggio email (diciamo 10 MB di massimo?) che la sua copia criptata significava , per server con molto traffico, un overhead inutile. Il comando in se' e' grande 16KB, non vedo perche' duplicare MB di ram. Peraltro, su Solaris il tmpfileszstem e' di default gia' in RAM, quando non swappato. Non vedo il problema, visto che come ho detto il file temporaneo contiene il messaggio gia' criptato: andra' comunque nella vostra casella postale, esattamente identico. E la casella e' un file sul filesystem, quando non un record su un database.
Un'altra cosa che ho scritto e' che gpgbody lavora tra standard input e standard output, gli errori vanno sullo standard error. CHi ha programmato in C e ha studiato Unix sa che significhi, ma a quanto pare c'e' chi usa pipes e redirezioni senza sapere che diavolo stia facendo. E' ovvio che se redirigete "2" sullo standard output, avrete i messaggi di errore dentro le email.
Allo stesso modo, se anche la vostra shell permettesse di passare nella riga di comando dei caratteri come "<" , ">", "|" etc, senza espanderli, gpg-body non lo accetterebbe ne' li passerebbe al sottostante gpg. Non accetto che un comando che puo' teoricamente acquisire la personalita' del superutente quando si invia posta a root possa venire arbitrariamente rediretto su un file qualsiasi o su un comando qualsiasi. Teoricamente dovrebbe essere la shell a fare questi controlli, ma per sicurezza gpg-body non accetta roba simile. Magari vi poteva tornare comoda, lo so. Ma e' una porcheria.
Allo stesso modo, se anche la vostra shell permettesse di passare nella riga di comando dei caratteri come "<" , ">", "|" etc, senza espanderli, gpg-body non lo accetterebbe ne' li passerebbe al sottostante gpg. Non accetto che un comando che puo' teoricamente acquisire la personalita' del superutente quando si invia posta a root possa venire arbitrariamente rediretto su un file qualsiasi o su un comando qualsiasi. Teoricamente dovrebbe essere la shell a fare questi controlli, ma per sicurezza gpg-body non accetta roba simile. Magari vi poteva tornare comoda, lo so. Ma e' una porcheria.
Vexata quaestio: ma oltre che per ricevere , posso crittare l'email sul destinatario anche nella coda di invio del server? Attualmente, quando pgp_body non trova una chiave esce restituendo l'input cosi' com'era. Anche se non ho collaudato la cosa a dovere, se due organizzazioni condividono un keyserver possono inserire (pensando a Postfix) il comando in master.cf e fargli effettivamente criptare il traffico in uscita. Quando gpg-body riceve un messaggio gia' criptato, infatti, non lo cripta la seconda volta: il server di destinazione , se usa gpg_body, lo lasciera' in pace.
Non ho pero' testato specificatamente questa opzione, che necessita di un controllo pesante delle condizioni di uscita, (dove pesante=transazionale) quindi o lo testate voi (e mi fate sapere), oppure lo fate a vostro rischio. Se lo dovessi fare io, semplicemente farei passare la posta in uscita per gpg_body solo quando va verso server che sappiamo usare gli stessi keyserver. Man transport (su postfix) per chi vuole sapere come.
Quali sono i rischi?
Il rischio e' che qualcuno abbia installato una volta, per provare, tanti anni fa una chiave pubblica (valida in eterno, of course) e poi, dopo aver formattato e riformattato, abbia perso le sue chiavi. In tal caso, state rendendo illeggibile la sua posta. Il rischio puo' essere mitigato creando una chiave per il server e aggiungendo una opzione --encrypt-to , facendo "Encrypt to self", in modo che il sysadmin possa comunque aiutare il malcapitato in caso di emergenza.(Anche se e' colpa sua, quindi di per se' dovrebbe soffrire ed espiare il suo peccato di non aver revocato le chiavi sui server pubblici).
Altra domanda che mi viene posta: ma ci sara' anche una versione che de-cripta , cosi' eventualmente si potra' installare sui server la chiave privata? CI sono, sembra persone che non usano e non vogliono usare Thunderbird e Enigmail.
La risposta e' che una simile utilita' e' un indebolimento della sicurezza notevole, anche perche' richiederebbe di lasciare sul server un database di passphrase, e non scrivero' nessuna porcheria del genere. Risolvere questo problema fa parte del blueprint della 3.0: poiche' tutti i programmi di email mainstream, anche dove non sia installato gpg o Enigmail, supportano S/MIME con chiavi RSA standard, la versione 3.0.X uscira' in due versioni, una con gpg e una con openssl.
La risposta e' che una simile utilita' e' un indebolimento della sicurezza notevole, anche perche' richiederebbe di lasciare sul server un database di passphrase, e non scrivero' nessuna porcheria del genere. Risolvere questo problema fa parte del blueprint della 3.0: poiche' tutti i programmi di email mainstream, anche dove non sia installato gpg o Enigmail, supportano S/MIME con chiavi RSA standard, la versione 3.0.X uscira' in due versioni, una con gpg e una con openssl.
Quella con openssl usera' chiavi identiche a quelle richieste da Outlook , ma anche Thunderbird, e anche i client per i dispositivi mobili, ove gpg e' raro e poco implementato. In questo modo bastera' avere il client di posta elettronica e le chiavi installate per leggere tutto senza dover installare ulteriore software o dover cambiare programma.
L'ultima domanda che mi e' stata posta e': posso partecipare?
La risposta e' che "se vi conosco" si. So che diversi enti non amano la mia idea, perche' sequestrando un server con la scusa che UNA email e' criminale non possono piu' leggere TUTTA la email ivi contenuta. E so che hanno una gran voglia di infilarci delle backdoor.
Sebbene il codice da sorvegliare sia poco, non ho intenzione di andare in paranoia ogni volta che uno scrive codice usando una scrittura poco familiare per me.
Quindi, se vi conosco e mi fido abbastanza e' ok: fatevi un account su launchpad e vi aggiungo. Aspettate solo che il software sia splittato in classi, cosi' non si fanno ancora piu' spaghetti e sia possibile la manutenzione.
Altrimenti no, grazie.
Altrimenti no, grazie.
Ah, giusto: come mai lo sto facendo e pubblicizzando specialmente in Italia? Perche' avete gia' un serio problema di insicurezza delle comunicazioni, di spionaggio della posta elettronica, di "informatori" che portano la vostra posta in caserma da dentro le aziende, di investigatori privati che pagano i sysadmin per portare fuori la posta, di impiegati precari che leggono la posta nei server che amministrano, e una polizia/magistratura che se ne fotte dei vostri diritti costituzionali. Ne avete bisogno.
Puo' bastare?
Uriel