sbarrax

Formati Aperti

Formati Aperti‘ nasce con l’intento di aiutare a capire l’importanza di disporre di formati di file che garantiscano realmente la libertà di fruizione del software e l’interoperabilità dei programmi stessi.
  I documenti presentati sono eterogenei, ma le diverse estrazioni culturali vengono ravvicinate da un unico scopo: vedere un giorno software diversi parlare tra di loro senza difficoltà, portando cosi’ la tecnologia informatica al servizio dell’uomo e non viceversa.

La pagina, nata come progetto insieme allo Staff di SL.kuht.it, è in continuo aggiornamento al link: http://softwarelibero.kuht.it/risorse/freelosofy/formati_aperti.php; ecco i documenti principali:

“Possiamo mettere fine agli allegati Word” (di Richard M. Stallman) – [ versione originale ]

“Open source versus open standards”
Articolo di J. Schwartz (vice presidente di Sun Microsystems) che illustra alcuni punti di vista sulla necessità di avere standard aperti ancor prima del codice sorgente aperto.
Passo fondamentale: “Aprire il codice sorgente é buona cosa, ma non significa necessariamente che tutto quello che la community produce sia poi compatibile. Ecco, una volta di più, il perché gli standard siano il fattore più importante.”

“Libertà, trasparenza e compatibilità”
“Non é solo un problema di software. Il ruolo fondamentale nella scuola nel definire una cultura – soprattutto umana – nell’uso dei sistemi di informazione e comunicazione” (G. Livraghi su Alcei.it)

E’ compito delle istituzioni pubbliche liberarci dalla schiavitù elettronica
ALCEI – Comunicato Stampa del 28 gennaio 1999 – é compito delle istituzioni pubbliche liberarci dalla schiavit elettronica. Il problema é grave e sta peggiorando. C’é una soluzione: sistemi aperti, trasparenti e compatibili in tutti i servizi pubblici. Occorre una decisione chiara delle autorità italiane ed europee.

Gli e-book sono davvero dei libri?
(Quali e-book per la didattica e la ricerca?) Gli e-book sono davvero dei libri? Otto tesi su cosa i libri elettronici non dovrebbero essere (di Gino Roncaglia)

– ‘ Il formato RTF puo’ considerarsi “Aperto” ?‘ (dall’archivio ml di AsSoLi)

Progetto Linguistico Italiano OpenOffice.org (PLIO)
Il Progetto Linguistico Italiano OpenOffice.org (PLIO) illustra la propria posizione davanti alla Commissione ministeriale per il software a codice sorgente aperto.

“Perché usare formati aperti ?”
Interessante pagina nella quale Bastien Guerry e Dario Taraborelli illustrano in una sorta di panoramica botta e risposta, la questione dei Formati Aperti

The Xiph.org Foundation
“Manifesto” di Xiph.org, il gruppo che ha dato vita al progetto Ogg/Vorbis, sinonimo di standard audio aperto per software libero.

GPG e crittografia dei documenti

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…

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

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

Le Case della Liberta'

PER PUBBLICAZIONE IMMEDIATA
Comunicato stampa della Free Software Foundation Europe (FSF Europe)

TRASFORMARE OGNI COMPUTER D’ITALIA IN UNA PICCOLA CASA DELLE LIBERTA’

A proposito della modernizzazione tecnologica del paese, invitiamo il
Presidente Silvio Berlusconi a chiedere consiglio non solo a Bill Gates
che verra’ a Roma il 31 gennaio, ma anche a noi.

La nostra ambizione e’ quella di trasformare ogni computer italiano in
una piccola casa delle liberta’ tramite l’uso di software libero:

Parliamo infatti delle liberta’
– liberta’ di utilizzare il software per qualsiasi scopo
– liberta’ di studiarlo e adattarlo alle nostre esigenze
– liberta’ di copiarlo per chi vogliamo
– liberta’ di distribuire le nostre copie modificate

E’ infatti un peccato costringere gli utenti ad acquistare i programmi
di base come il sistema operativo, i programmi di videoscrittura e
quelli per sfruttare la rete, in versione proprietaria, quando esistono
dei loro equivalenti che non limitano la liberta’ di azione di chi li
installa. Inoltre tali programmi liberi sono spesso disponibili a
prezzi molto contenuti, rispettando la volonta’ dei rispettivi autori e
sempre completamente a norma di legge.

Sono proprio i termini di licenza restrittivi che ostacolano la
diffusione delle tecnologie nel nostro Paese, portando ad uno spreco di
risorse economiche e intellettuali, risorse che potrebbero essere
investite in attivita’ pi proficue per le imprese e per le Pubbliche
Amministrazioni del nostro Paese.

E’ per questo che offriamo al Presidente del Consiglio un CDROM
contenente una selezione di software libero, perche’ lo possa esaminare
in prima persona sul proprio elaboratore e fornirne copie ai propri
familiari e collaboratori.

I programmi contenuti, oltre ad essere pienamente funzionali, hanno il
pregio di poter essere legalmente redistribuiti grazie alla licenza GNU
GPL utilizzata dai rispettivi autori.

Questi programmi permettono tutt’ora a centinaia di liberi
professionisti ed imprese del nostro Paese di lavorare e produrre in
ambito tecnologico valorizzando la propria professionalita’ senza
doversi limitare alla redistribuzione onerosa di programmi che non
possono controllare.

Il software libero offre delle reali possibilita’ di sviluppo economico,
permettendo la creazione di nuovi posti lavoro, e non necessita
investimenti tanto diversi quanto una solida formazione Unix che
qualsiasi facolta’ di ingegneria e’ gia’ in grado di fornire.

Ecco quindi il nostro consiglio, signor Presidente: per modernizzare la
tecnologia del nostro Paese si informi sul software libero. Avra’ la
soddisfazione di vedere nel computer di ogni famiglia del Belpaese una
piccola casa delle liberta’

—-

Il CDROM che inviamo al presidente Berlusconi pu essere liberamente
scaricato all’indirizzo:
http://www.ofset.org/projects/edusoft/edusoft.html

Se ci fossero problemi, ve lo possiamo mandare via posta, chiedere a:
italy@fsfeurope.org

—-

Che cos’e’ la Free Software Foundation Europe:

La Free Software Foundation Europe – pendant europeo della Free
Software Foundation – e’ l’organismo disponibile per tutte le questioni
che riguardano il Software Libero in Europa.

Promuove il Software Libero offrendo attivamente se stessa come centro
di competenza e cercando il dialogo con i politici e la stampa. Coopera
anche con avvocati in tutta Europa per massimizzare la sicurezza della
legalita’ del Software Libero. Supporta, coordina e sviluppa progetti
nel campo del Software Libero, specialmente il Progetto GNU.

Fornisce anche risorse di calcolo per sviluppatori di Software Libero
per permettergli di continuare a svilluppare. Aiuta le societa’ a
sviluppare modelli di business basati su Software Libero o adatta
modelli esistenti ad esso; incoraggia le societa’ nella loro evoluzione
verso il Software Libero.

FSF Europe aiuta a coordinare e connettere altre iniziative nel campo
del Software Libero.

Per maggiori informazioni: http://fsfeurope.org/

Contatti:

Stefano Maffulli <maffulli@fsfeurope.org>
Tel: +39-02-3651.4266
Cel: +39-347-1493.733
Fax: +39-055-489.457

Christopher Gabriel <gabriel@fsfeurope.org>
Tel: +39-0574-337.19
Cel: +39-347-7784862

Alessandro Rubini <rubini@fsfeurope.org>
Tel: +39-0382-529.554
Cel: +39-349-2689.041

Maggiori informazioni per la stampa sono disponibili su:
http://fsfeurope.org/press/

—- FINE COMUNICATO

Parliamo di Software Libero

Si ricorda che l’iniziativa Parliamo di Software Libero e’ fonte di riflessione e di spunto per chi abbia dei dubbi sui valori e le potenzialita’ del Software Libero, o per chi semplicemente stia cercando di approfondire l’argomento.