..::.. liberi cantieri ..::..
documentation
GPG e crittografia dei documenti
Apr 6th
Posted by sbarrax in documentation
Se voglio spedire un documento criptato al mio destinatario, usero’ la sua chiave pubblica per farlo.
Sempre dalla nostra beneamata linea di comando:
$ gpg –output thedoc.pgp –encrypt –recipient trusted@myfriends.net thedoc.rtf
–output nomefile specifica il nome del file criptato
–encrypt e’ l’opzione per cifrare
–recipient indirizzo_di_cui_possiedo_chiave_pubblica per specificare il destinatario del documento
nome_file_documento
Un file crittato con il comando riportato qui sopra sara’ possibile decrittarlo con
$ gpg –output thedoc –decrypt thedoc.gpg
–decrypt nome-file-crittato specifica il nome del file da decifrare
–output thedoc specifica il file su cui trasferire l’output (se viene omesso, il documento decifrato viene sparato su standard output)
Guardiamo
adesso ad un altro interessante aspetto: la firma digitale di un documento. Essa, oltre a certificare la provenienza del documento, ne fissa la data di ultima modifica; puo’ quindi venire utilizzata come strumento per scoprire eventuali manomissioni.
Al contrario di quello che avviene per la cifratura che abbiamo visto qui sopra, la
firma digitale si realizza utilizzando la chiave privata, e puo’ essere verificata da chi e’ in possesso della corrispondente chiave pubblica.
$ gpg –output thedoc.signed –sign thedoc
come al solito con l’opzione –output andiamo a specificare il file di destinazione (che sara’ il documento firmato) mentre thedoc e’ il documento originale da firmare
l’esecuzione di questo comando richiedera’ naturalmente la digitazione della passphrase; da notare che l’output (binario) sara’ compresso.
a questo punto si possono fare due cose col documento firmato:
1) verificare semplicemente l’autenticita’ della firma ($ gpg –verify thedoc.signed)
2) …anche estrarre il documento originale ($ gpg –decrypt thedoc.signed –output thedoc)
oltre alla firma digitale in formato binario appena vista, e’ possibile firmare i documenti in chiaro ($ gpg –clearsign $thedoc) che praticamente ingloba il documento originale in un blocco ASCII-armored senza modificarne il contenuto.
Se
altri utenti, come e’ molto frequente che avvenga, dovranno successivamente editare/firmare il documento, si utilizza la cosiddetta “firma distaccata”, che produce un nuovo file di firma legato pero’ strettamente al file originale (servono sia il documento primario che tutte le firme distaccate per poter verificare od estrarre il documento
originale, cio’ indipendentemente dal fatto che la firma sia stata fatta in chiaro o binaria).
il comando per generare una firma distaccata e’ : $ gpg –output thedoc.signed –detach-sig detf
per la verifica $ gpg –verify thedoc.signed detf (e’ come se il documento firmato e la firma distaccata fossero un tutt’uno ai fini della decifratura).
_
Vi rimando come sempre al Manuale GNU sulla privacy per un completo approfondimento.
Intro al CVS…
Apr 6th
Posted by sbarrax in documentation
INTRO
CVS e’ un sistema di controllo di versione nato alla fine degli anni ottanta, basato su un precedente software analogo (RCS).
CVS e’ essenzialmente un sistema che permette di tener traccia delle modifiche apportate ai sorgenti di vari progetti, mantenendo una sorta di ‘database centrale’ di tale sorgenti (il ‘repository’).
Per fare cio’ si serve di un programma (un unico eseguibile chiamato anch’esso ‘cvs’) che si occupa di trasferire i file da e per il repository, gestendo le modifiche apportate in base alle differenze tra la copia locale del sorgente e la copia presente nel repository (proprio come un
comando ‘diff’).
L’architettura di lavoro vede quindi 2 ambienti: la propria copia locale appunto, dove si editano, compilano e testano i file dei progetti, ed il repository, che ha la funzione di contenitore dei sorgenti testati/approvati.
ATTENZIONE! Cvs non include un sistema di testing, ne’ di compilazione, e non va a sostituire la comunicazione tra gli sviluppatori; non fornisce pertanto automatismi
sulle decisioni da prendere in base alle modifiche apportate
(in parole povere: se in due si e’ modificato lo stesso sorgente, e vi sono dei conflitti su tali modifiche, cvs non e’ in grado di suggerire quale versione sia da considerare “buona” o migliore, ma devono essere gli sviluppatori a confrontarsi e decidere quali sono le modifiche da tenere).
Cvs e’ free software; indirizzi di riferimento:
http://www.cyclic.com
http://www.loria.fr/~molli/cvs-index.html
http://cvshome.org/
Ecco il minitutorial vero e proprio… e’ particolarmente pensato a chi opera su
piattaforme *nix, ma se si escludono i comandi di sistema, la configurazione di cvs e’ pressoche’ identica anche su win32 ed altre piattaforme.
MODALITA’ CVS
Vi sono due modalita’ fondamentali di lavoro con cvs: con repository locale o con
repository remoto (detta anche ‘client/server’).
A determinare la modalita’ di lavoro e’ il contenuto della variabile d’ambiente $CVSROOT (%CVSROOT% su win) settata sul client, oppure l’equivalente opzione “-d …” data al comando.
A sua volta poi la modalita’ con repository remoto puo’ essere effettuata con diversi metodi di accesso:
pserver (autenticazione normale con pwd in chiaro), via rsh o ssh, mediante GSSAPI (autent. Kerberos)
LAVORARE CON CVS
Possiamo dire che, dal punto di vista dello sviluppatore, cvs si integra nel lavoro quotidiano alla perfezione, e la sua adozione e’ possibile in pressoche’ qualunque ambiente di sviluppo in circolazione, sia esso software libero o proprietario (pensate che e’ possibile anche sostituire VisualSourceSafe con cvs all’interno dell’ambiente di sviluppo Visual Studio della Microsoft).
All’atto pratico, pochi semplici gesti in piu’ rispetto allo sviluppo senza controllo di versione, e tutto il lavoro si arricchisce di enormi possibilita’ ed impagabili comodita’:
-
il normale ciclo di lavoro si compone di 4 fasi fondamentali: messa in stato di “editing” di uno o piu’ sorgenti interessati alle modifiche, modifiche vere e proprie sui file, test, conferma (“commit”) delle modifiche con un commento adeguato (il commit togliera’ lo stato di editing dai sorgenti confermati);
- prima di lavorare su un sorgente, e’ buona norma aver aggiornato la propria copia locale, per diminuire la probabilita’ di dover fronteggiare conflitti rispetto a modifiche di altri sviluppatori;
- e’ possbile, giocando con le varie possibilita’ che le opzioni di cvs offrono, ottenere facilmente un changelog accurato; o il dettaglio granulare delle modifiche fatte da una revisione all’altra, per non parlare dei grafici che possono essere generati in base al log tree e che rendono in maniera molto efficace l’andamento dello sviluppo di un progetto;
- last but not least… lavorare con cvs significa, per un team, non essere mai fermi, in quanto e’ possibile (ed anzi: e’ il suo forte) lo sviluppo concorrenziale dello stesso sorgente, dal momento che le modifiche e i test avvengono in ambienti fisicamente separati (le “sandboxes”).
CONFIGURAZIONE CVS: Il repository
- Come utente root, creare utente ‘cvs’ con gruppo primario ‘cvs’;
- creare una directory ‘repository’ all’interno della home dir. dell’utente cvs;
-assicurarsi che tutti gli utenti che debbano accedere al repository appartengano (anche solo come gruppo secondario) al gruppo ‘cvs’.
- Impostare i permessi del repository a ‘770′ (rwxrwx—), ed anche il bit s sul gruppo (“chmod g+s /home/cvs/repository”): questo fa si’ che i nuovi file creati nel repository appartegano allo stesso gruppo a cui appartiene la dir. repository stessa anziche’ al gruppo dell’utente che ha aggiunto i nuovi file.
A questo punto bisogna inizializzare il repository (questa operazione crea una struttura particolare di directory e di file amministrativi che servono all’eseguibile ‘cvs’ per lavorare)
il comando di inizializzazione e’: cvs -d “dir_del_repository” init
esso viene lanciato, dall’amministratore del repository, solo la prima volta che si va a configurare il repository.
CONFIGURAZIONE CVS: La copia locale (detta anche ’sandbox’ o ‘working copy’)
Cvs
per lavorare ha bisogno della variabile di shell CVSROOT che indichi la modalita’ di accesso al repository, oppure ogni comando deve avere come primo parametro “-d dir_del_repository”
- Settaggio variabile d’ambiente
nel caso di repository locale:
$ export $CVSROOT=dir_del_repository
nel caso di repository remoto, il formato di tale variabile sara’:
:metodo_accesso:utente@hostname:dir/del/repository
dove dir/del/repository e’ sempre il path reale del repository sulla macchina remota (’server’)
- Inserimento di un nuovo progetto sotto cvs
$ creazione della directory del progetto nella propria home
$ cd directory del progetto
$ cvs import “dir_del_progetto” nomeutente start
$ rmdir dir_del_progetto
poi usare
$ cvs -r co dir_del_progetto
per avere la copia del progetto sotto cvs
PRINCIPALI COMANDI CVS
- cominciare a lavorare e prendere le ultime versioni aggiornate
da lanciare nella directory padre della copia locale (crea automaticamente la directory del progetto)
$ cvs -r checkout “nomeprogetto” -dP
- aggiungere un nuovo file al repository
$ creare il file
$ cvs add “nomefile”
- se il file e’ binario
$ cvs add -kb “nomefile”
- togliere un file
$ cvs remove -d “nomefile”
- confermare i cambiamenti (modifiche ai sorgenti, aggiunta o rimozione di file)
$ cvs commit -> apre vi per la scrittura del log
oppure
$ cvs commit -m”messaggio di log”
- chiedere i log
$ cvs log [nomefile]
- chiedere lo stato dei file
$ cvs status [nomefile]
- cancellare un progetto locale (nella directory padre del progetto)
$ cvs release -d “progetto”
- fissare una versione
il nome della versione deve essere senza “.”: ad esempio, rel-1-0
$ cvs rtag “nome_versione” “nomeprogetto”
- prendere tutto il progetto per la distribuzione con i file piu’ recenti
$ cvs export -r HEAD “nomeprogetto”
- prendere tutto il progetto per la distribuzione di una certa versione
$ cvs export -r “nome_versione” “nomeprogetto”
- vedere le versioni
$ cvs history -xT -a
EDITING DEI FILE
- Editing normale
$ cvs edit [nomedelfile]
$ vi [nomedelfile]
$ cvs unedit [nomedelfile]
oppure se si vogliono anche confermare i cambiamenti
$ cvs commit
- edit con lock
$ cvs admin -l [nomedelfile]
$ vi [nomedelfile]
$ cvs admin -u [nomedelfile]
(!) prima di editare il progetto e’ bene dare il comando
$ cvs update
per avere le ultime versioni dei file
——————————————————
Risorse
1) CVS Home (http://cvshome.org/)
2) “Installing adn Configuring CVS on RedHat Linux 7 as an SCM Repository” (http://www7b.software.ibm.com/wsdd/library/techarticles/0205_yu/yu.html)
3) LinCVS (http://lincvs.org/)
4) Cervisia (http://cervisia.sourceforge.net/)
——————————————————
Copyright e Autorizzazione:
Copyright (2002-2003) by Domenico Ferrari (aka dome) and Marco Frattola (aka sbarrax).
La copia e la distribuzione integrale dell’ articolo sono permessi in qualsiasi forma e mezzo a condizione che l’indicazione del copyright e questa nota siano riportate.
Per qualsiasi segnalazione mandate email all’indirizzo: framar@sbarrax.it
——————————————————
firma digitale e uso di gpg
Feb 23rd
Posted by sbarrax in documentation
Per prima cosa bisogna generare la propria coppia di chiavi (privata+pubblica)
$ gpg –gen-key
Subito dopo e’ buona cosa generare il certificato di revoca; l’output di
questo comando, sia esso stampa o file, e’ da conservare in un luogo
sicuro.
$ gpg –output revoca.asc –gen-revoke id_mia_chiave
Per
scambiare col mondo esterno la propria chiave pubblica, e’ necessario
esportarla (al posto di id_mia_chiave posso usare una part qualunque
dello User ID)
$ gpg –output marco.gpg –export id_mia_chiave
al posto di esportare in formato binario, si puo’ esportare in formato testo (”Armatura ASCII”):
$ gpg –armor –export id_mia_chiave > marco.asc
A questo punto andiamo a importare le chiavi pubbliche dei ns. interlocutori (dicesi “aggiungere al mazzo di chiavi”)
$ gpg –import valerio.gpg
Le
chiavi pubbliche cosi’ importate mancano pero’ della convalida: questa
si puo’ ottenere andando ad editare la chiave importata e verificare,
col possessore originale della chiave, la cosiddetta “impronta
digitale” (fingerprint)
$ gpg –edit-key valerio@valerio.net
pub 1024D/A10AF6FF created: 2002-12-08 expires: never trust: -/q
sub 1024g/14A33CD0 created: 2002-12-08 expires: never
(1). valerio <valerio@valerio.net>
Comando> fpr
pub 1024D/A10AF6FF 2002-12-08 valerio <valerio@valerio.net>
Fingerprint: 0DA1 6E42 7337 EB35 D478 0BAB 2230 AA19 A11A F6E1
Comando> sign
Comando> check
(In realta’ questi passaggi si possono “forzare”, cioe’ si puo’ fare il sign di una chiave senza aver controllato il fingerprint, ma e’ sconsigliabile… si presurrebbe cosi’ un trust troppo alto della fonte della chiave)
Per controllare le chiavi “del mazzo”:
$ gpg –list-keys
Tutto questo risulta molto comodo per quello puo’ essere anche solo lo
scambio di email firmate con gpg; KMail a tal proposito offre un’integrazione con lo standard OpenPGP veramente facile e comoda da usare.
__
Questo e’ tutto per quanto riguarda la firma dei messaggi con gpg.
Il prossimo passo sara’ vedere insieme la firma dei documenti.
“/x”
[liberamente ispirato dal "Manuale GNU sulla privacy" di Mike Ashley (traduzione italiana di Lorenzo Cappelletti)]
_
PS: valerio@valerio.net e’ un indirizzo di fantasia










Ultimi Commenti