Hardening Apache, download e installazione

Zarrelli il giovedì, 2 Febbraio, 2006

Aprire una porta su internet, lasciare che ignoti visitatori entrino e diano uno sguardo nell’anticamera del vostro server è sicuramente un’operazione affascinante e, spesso, utile. Un server web dovrebbe proprio servire a questo, a creare uno spazio destinato ad accogliere le richieste più diverse, a mostrare le informazioni che si vogliono condividere. Con il tempo, però, le esigenze sono cresciute, sono divenute più sofisticate, tanto che il semplice HTML è diventato un linguaggio inadeguato ai nuovi scopi: pagine dinamiche, applicazioni su web, portali, weblog e tutta la teoria di strumenti interattivi ha reso più sofisticati i siti e più complessi i server web alle loro spalle.
Apache è un ottimo esempio di server versatile, potente e, tutto sommato, semplice da configurare: può essere utilizzato da un utente di media esperienza per gestire il proprio sito Internet, come lo si può riscontrare in portali o siti di classe enterprise a servire intranet ed extranet più simili a vere e proprie applicazione browser-driven che a pagine di consultazione. Proprio la notevole interattività delle applicazioni che possono essere costruite attorno a un web server ha portato all’emergere, nel corso degli anni, di una serie di problematiche legate alla sicurezza sia del framework, Apache, che dei programmi, scritti nei più disparati linguaggi, dal Perl o C, per esempio, alle pagine PHP o JavaScript. Insomma, all’aumentare dell’interattività delle pagine web è corrisposta una crescita considerevole dei problemi legati alla sicurezza e delle contromisure che un amministratore di sistema deve essere in grado di porre in campo per assicurare una discreta sicurezza alle proprie installazioni.

Sicurezza stratificata

Cosa comporta mettere in sicurezza un web server?
Il problema, come spesso accade, si riflette su diversi livelli di amministrazione su un server:

  1. Mettere in sicurezza il sistema operativo;
  2. Mettere in sicurezza il framework (Apache);
  3. Mettere in sicurezza le applicazioni.

In questa occasione tralasceremo la sicurezza relativa al sistema operativo, un’operazione decisamente complessa che richiederebbe un intero ciclo di articoli a se stante. Di passaggio possiamo solo fornire un suggerimento: una prima soluzione potrebbe consistere nel ricompilare il kernel utilizzando le patch grsecurity (www.grsecurity.net), impostando un alto livello di protezione. Non è la soluzione ottimale, dato che la difesa di un sistema operativo si basa anch’essa su più livelli di intervento, che vanno dalla ricompilazione dei sorgenti degli applicativi alle operazioni, almeno le più elementari, di auditing; però, l’installazione di grsecurity può essere un primo punto di approccio al problema, dal quale partire e approfondire in seguito.

Ciò che qui ci interessa è, primariamente, rendere più affidabile Apache, partendo dalle “radici” del problema, iniziando a lavorare a livello di sorgente, per assicurarci della bontà del programma e per mettere in gioco qualche diversivo in grado di disorientare i malintenzionati meno ferrati in materia di sicurezza.

Il nostro primo passo sarà, quindi scaricare i sorgenti di Apache: è indifferente quale si decida di utilizzare, se appartenente alla versione 1.x o alla 2.x.

Verifichiamo i sorgenti

La prima buona pratica da tenere a mente è quella di preferire i server ufficiali del progetto Apache come fonte dalla quale scaricare i sorgenti sui quali si vuole lavorare. E’ una semplice questione di sicurezza: è decisamente più difficile per qualche malintenzionato penetrare in queste macchine piuttosto che in un computer gestito in maniera amatoriale da qualche volenteroso.

Una volta ottenuti i sorgenti, proseguiamo con una verifica della loro bontà: ogni sorgente fornito ufficialmente dal progetto Apache viene firmato digitalmente dal gestore della versione rilasciata e quindi bisognerà provvedere a scaricare sia le firme PGP che gli hash MD5.

Nel nostro esempio utilizzeremo i sorgenti contenuti nell’archivio:

httpd-2.0.54.tar.gz

Una volta scaricato il sorgente, dobbiamo prelevare anche la relativa firma PGP e l’hash MD5:

httpd-2.0.54.tar.gz.md5
httpd-2.0.54.tar.gz.asc

Provvediamo a confrontare la firma ottenuta con i sorgenti scaricati, utilizzando un tool di gestione quale potrebbe essere GNU Privacy Guard:

~$ gpg httpd-2.0.54.tar.gz.asc
gpg: Signature made lun 11 apr 2005 23:06:14 CEST using DSA key ID DE885DD3
gpg: Impossibile controllare la firma: chiave pubblica non trovata

Qui incontriamo il primo ostacolo. Non possiamo controllare la bontà dei sorgenti, dato che non abbiamo la chiave pubblica corrispondente. Da notare che l’identificativo della chiave pubblica messa a disposizione dal gestore di questa versione dei sorgenti per verificare la loro integrità è:

DE885DD3

Il problema è di facile soluzione: basterà utilizzare un gestore pubblico di chiavi per scaricare quella corrispondente all’identificativo indicato. Nel nostro caso useremo keyserver.linux.it, il quale è fornito anche di una comoda interfaccia web che facilita notevolmente il compito a chi si trova un po’ a disagio nell’utilizzo di gpg:

~$ gpg --keyserver keyserver.linux.it --recv-key DE885DD3
gpg: requesting key DE885DD3 from hkp server keyserver.linux.it
gpg: key DE885DD3: public key "Sander Striker " imported
gpg: non è stata trovata alcuna chiave definitivamente affidabile
gpg: Numero totale esaminato: 1
gpg: importate: 1

Abbiamo installato la chiave pubblica che ci interessa, prendendola da keyserver.linux.it: dato che i key server sono interconnessi fra di loro e si scambiano le chiavi, ognuno può scegliere quello che ritiene migliore e più affidabile.

Possiamo ora verificare che la firma apposta ai sorgenti sia buona e lo faremo utilizzando la chiave fornita da Sander Striker tramite il key server:

$ gpg httpd-2.0.54.tar.gz.asc
gpg: Signature made lun 11 apr 2005 23:06:14 CEST using DSA key ID DE885DD3
gpg: Good signature from "Sander Striker "
gpg: aka "Sander Striker "
gpg: ATTENZIONE: questa chiave non è certificata con una firma fidata!
gpg: Non ci sono indicazioni che la firma appartenga al proprietario.
Impronta digitale della chiave primaria: 4C1E ADAD B4EF 5007 579C 919C 6635 B6C0 DE88 5DD3

Attenzione. Abbiamo una buona e una cattiva notizia:

  • La buona notizia consiste nel fatto che la firma sui sorgenti è buona;
  • La cattiva è che la chiave con cui abbiamo gestito la verifica non è affidabile.

Chiunque potrebbe creare un chiave pubblica corrispondente a una firma falsa sui sorgenti scaricati e indurci a credere che sia tutto a posto. Dobbiamo fare un passo ulteriore: siamo costretti a verificare che la chiave connotata dall’identificativo DE885DD3 sia stata creata davvero da Sander Striker, ovvero dobbiamo validarla:

$ gpg --fingerprint DE885DD3
pub 1024D/DE885DD3 2002-04-10
Key fingerprint = 4C1E ADAD B4EF 5007 579C 919C 6635 B6C0 DE88 5DD3
uid Sander Striker
uid Sander Striker
sub 2048g/532D14CA 2002-04-10

In questo caso abbiamo verificato l’impronta della chiave che abbiamo scaricato, ma nemmeno questo è sufficiente. Ciò che ci potrebbe aiutare è entrare in un web of trust, ovvero costruire una rete di referenti affidabili, da cui abbiamo ricevuto direttamente l’impronta delle loro chiavi e quindi siamo sicuri della loro identità. Se una delle maglie di questa rete ci porta a qualcuno che ha firmato la chiave di Sander Striker, potremo considerare affidabile la chiave di quest’ultimo e tutte le chiavi da lui firmate. Il metodo più affidabile per verificare la chiave di qualcuno è scambiare l’impronta “de visu”, in modo da essere sicuri di chi ci sta fornendo l’informazione, ma questo è possibile solo per i nostri referenti diretti. Per poter ovviare al problema di incontrare faccia a faccia Sander Striker, operazione difficile e scomoda, possiamo scaricare dal sito del progetto Apache il file

http://www.apache.org/dist/httpd/KEYS

contenente le chiavi pubbliche degli sviluppatori di Apache. Dato che gli sviluppatori hanno firmato reciprocamente le loro chiavi, considerando valide le chiavi pubbliche di uno, verranno considerate valide tutte:

$ gpg --edit-key DE885DD3
gpg (GnuPG) 1.4.1; Copyright (C) 2005 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.

gpg: controllo il trustdb
gpg: non è stata trovata alcuna chiave definitivamente affidabile
pub 1024D/DE885DD3 created: 2002-04-10 expires: mai usage: CSA
trust: undefined validity: sconosciuto
sub 2048g/532D14CA created: 2002-04-10 expires: mai usage: E
[ unknown] (1). Sander Striker
[ unknown] (2) Sander Striker

Comando> trust
pub 1024D/DE885DD3 created: 2002-04-10 expires: mai usage: CSA
trust: undefined validity: sconosciuto
sub 2048g/532D14CA created: 2002-04-10 expires: mai usage: E
[ unknown] (1). Sander Striker
[ unknown] (2) Sander Striker

Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)

1 = I don't know or won't say
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
5 = I trust ultimately
m = back to the main menu

Cosa hai deciso? 5
Do you really want to set this key to ultimate trust? (y/N) y

pub 1024D/DE885DD3 created: 2002-04-10 expires: mai usage: CSA
trust: ultimate validity: sconosciuto
sub 2048g/532D14CA created: 2002-04-10 expires: mai usage: E
[ unknown] (1). Sander Striker
[ unknown] (2) Sander Striker
Nota che la validità della chiave indicata non sarà necessariamente corretta
finchè non eseguirai di nuovo il programma.
Comando> quit

A questo punto, la chiave di Sander Strike è considerata valida a tutti gli effetti. Proviamo ora a verificare i sorgenti:

$ gpg --verify httpd-2.0.54.tar.gz.asc
gpg: Signature made lun 11 apr 2005 23:06:14 CEST using DSA key ID DE885DD3
gpg: controllo il trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, classic trust model
gpg: depth: 0 valid: 1 signed: 3 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1 valid: 3 signed: 9 trust: 3-, 0q, 0n, 0m, 0f, 0u
gpg: Good signature from "Sander Striker "
gpg: aka "Sander Striker

La firma è considerata valida ed è stata utilizzata una chiave valida. Ovviamente, se riuscite a farvi dare l’impronta della chiave di prima mano, anche tramite un vostro buon web of trust, l’operazione è da considerarsi ancora più sicura.

Un secondo metodo per controllare l’integrità dell’archivio contenente i file sorgente è costituito nella verifica della sua firma MD5. Senza addentrarci troppo nei dettagli tecnici, possiamo definire la firma MD5 come una stringa a 128 bit (hash) generato in base a una stringa di partenza variabile. Data la stessa stringa di partenza, si otterrà sempre la stessa stringa di arrivo, ma non è vero il contrario: dal codice ottenuto non si può risalire alla stringa di partenza. Quindi, siamo di fronte a un algoritmo definito one way, che non consente praticamente a un malintenzionato di alterare i dati di partenza senza che questi si riflettano nel codice di controllo. E nemmeno è praticamente fattibile creare due stringhe di partenza che diano lo stesso hash finale. Insomma, data l’alta improbabilità di poter alterare la stringa di partenza senza che ciò alteri anche il codice di controllo, è possibile usare la l’algoritmo MD5, dandogli come input l’archivio contenente i file sorgente di Apache, per poi controllarne la stringa di hash con quella generata fornita tramite il sito del progetto: se i due hash corrispondono vi è una probabilità molto alta, talmente alta da dare una certezza pratica, che il file in nostro possesso non sia stato alterato. Controlliamo quindi la firma del nostro file, generandola tramite l’utility md5sum, contenuta nel pacchetto textutils, riversandola in un file temporaneo che confronteremo tramite diff con il file scaricato dal sito di Apache:

$ cat httpd-2.0.54.tar.gz.md5
772503748ffb85301385d47fb2b96eca httpd-2.0.54.tar.gz
$ md5sum httpd-2.0.54.tar.gz > verifica
$ diff verifica httpd-2.0.54.tar.gz.md5
$

L’output generato da diff è nullo, quindi i due file sono identici e ciò significa che la firma generata dal file in nostro possesso è identica alla firma generata con la copia ufficiale di Apache, quindi vi è un’alta probabilità che anche i due file di partenza siano identici.

Patchwork

Una volta ottenuti dei sorgenti affidabili, è necessario assicurarsi che questi siano privi di bachi sensibili.
Il primo accorgimento per evitare problemi nascosti nei sorgenti, consiste puntare all’URL http://archive.apache.org/dist/httpd/patches/ o a un mirror affidabile e aggiornato e controllare se per la versione in proprio possesso esiste una patch critica, che va quindi scaricata nella directory dei sorgenti e applicata utilizzando il comando:

patch -s < nome_patch.patch

Questo primo passo è necessario ma non sufficiente a garantire che i sorgenti siano privi di bachi importanti, dato che questi spesso vengono rilevati a distanza dal loro rilascio, evidenziati durante l'utilizzo su numerose installazioni. Per evitare di rimanere con un server afflitto da bachi è necessario rimanere sempre aggiornati sullo sviluppo dei sorgenti, iscrivendosi alla mailing list announce@httpd.apache.org

(che è più bollettino che mailing list vera e propria, dato che vi circolano solo gli annunci di nuove versioni o di patch, inviati dalla Fondazione). Se vi saranno aggiornamenti critici, una volta iscritti questi arriveranno comodamente nella vostra casella postale, mettendovi al riparo da future, sgradite sorprese.

Mistificazioni

Resistere all’attacco di un malintenzionato in gamba è decisamente difficile, ma togliersi di torno l’improvvisato di turno non è un’operazione che richieda grandi sforzi. Un semplice trucco per confondere le acque a chi stia cercando di collezionare più informazioni possibile sul nostro server, come per esempio la versione utilizzata (utile per cercare bachi non patchati), quale PHP o libreria SSL vengano implementate, è abbastanza semplice e richiede la modifica di un solo file header nei sorgenti.

Apache 1.x

Nella configurazione standard, Apache è decisamente “chiacchierone” e rivela fin troppo facilmente la propria versione e i vari moduli compilati, consentendo a chiunque, semplicemente richiamando una pagina esistente, di sapere se sono installati i moduli PHP e SSL e le relative versioni, per esempio. Troppo semplice e troppo invitante soprattutto per uno “script kiddie”, uno smanettone senza troppe competenze ma fornito all’inverosimile di script e programmi in grado di condurre autonomamente una vasta serie di attacchi.
Il nostro scopo, ora, consiste non solo e non tanto nell’ammutolire Apache, ma nel renderlo menzognero, facendogli dire qualche piacevole fandonia. Per raggiungere questo risultato, con i sorgenti della versione 1.x, basterà modificare il file

httpd.h

Nel nostro esempio, utilizzeremo i sorgenti contenuti nell’archivio

apache_1.3.33.tar.gz

Una volta decompresso, entriamo nella directory

apache_1.3.33/src/include

e apriamo in file httpd.h, nel quale troveremo alcune righe interessanti:

#define SERVER_BASEVENDOR "Apache Group"
#define SERVER_BASEPRODUCT "Apache"
#define SERVER_BASEREVISION "1.3.33"

#define APACHE_RELEASE 10333100
#define SERVER_SUPPORT "http://www.apache.org/"

Sono le informazioni contenute in queste direttive a essere utilizzate per generare i messaggi “di sistema” mostrati ai navigatori. Modifichiamoli leggermente:

#define SERVER_BASEVENDOR "Suppa Lovva Group"
#define SERVER_BASEPRODUCT "Lovva Server"
#define SERVER_BASEREVISION "1.2.3.4.x.x.x"

#define APACHE_RELEASE 99887766554433221100
#define SERVER_SUPPORT "http://www.suppalovva.net"

Ora basterà lanciare un semplice

./configure
make
make install

dalla directory radice dei sorgenti, avviare il server, richiamare una pagina inesistente e il risultato sarà quello visibile nella figura sottostante.

Lovva Server
Il nostro server appare decisamente strano. Suppa Lovva?

Apache 2.x

In Apache 2.x si può ottenere lo stesso risultato modificando un differente file. Nel nostro esempio, abbiamo decompresso l’archivio httpd-2.0.54.tar.gz, editando il file

httpd-2.0.54/include/ap_release.h

Al suo interno, ritroviamo delle stringhe decisamente familiari:

#define AP_SERVER_BASEVENDOR "Apache Software Foundation"
#define AP_SERVER_BASEPRODUCT "Apache"
#define AP_SERVER_MAJORVERSION "2"
#define AP_SERVER_MINORVERSION "0"
#define AP_SERVER_PATCHLEVEL "54"

Modifichiamole a piacere:

#define AP_SERVER_BASEVENDOR "Free Love Foundation"
#define AP_SERVER_BASEPRODUCT "StupidCupid"
#define AP_SERVER_MAJORVERSION "99"
#define AP_SERVER_MINORVERSION "00"
#define AP_SERVER_PATCHLEVEL "11"

Compiliamo i sorgenti, installiamoli, lanciamo Apache e richiamiamo una pagina inesistente. Il risultato sarà quello mostrato nella figura sottostante.

Stupid Cupid
Volendo giocare con gli header si possono apportare parecchie modifiche

Gli amministratori con uno spiccato senso dello humor potrebbero avere già inteso cosa si può fare giocando con gli header: basta modificare poche righe per simulare le risposte di IIS o di qualche altro server web a piacere.

La direttiva ServerTokens

Se vogliamo rendere la vita ancora più difficile al malintenzionato di turno, possiamo giocare un po’ con la configurazione del file httpd.conf, abilitando la direttiva ServerTokens, che gestisce la quantità di informazioni sul server restituite dagli header inviati da Apache ai client. Questa direttiva, però, è disponibile solo dalla versione 1.3 del server – ovviamente esiste anche nella 2.x, e accetta una serie di modificatori:

  • ServerTokens Prod(uctOnly)
    Viene inviato solo il nome del web server, per es: Server: Apache Server;

  • ServerTokens Min(imal)
    Viene inviata anche la versione, per es.: Apache/1.3.33 Server;

  • ServerTokens OS
    Viene inviato anche il tipo di sistema operativo: per es. : Apache/1.3.33 (Unix);

  • ServerTokens Full (o senza argomento)
    Vengono inviati tutti i dati possibili, compresi quelli relativi ai moduli compilatiServer sends (e.g.): Server: Apache/1.3.33 (Unix) PHP/5.0.5

Attenzione però: questa direttiva può essere abilitata solo a livello di server e non può essere modificata nei singoli host virtuali eventualmente configurati.

Prima di compilare

Questo primo articolo sulla sicurezza in Apache si chiude con un consiglio di buona condotta al momento di configurare i sorgenti per la compilazione del server. Seguendo il sempre valido motto KISS, Keep It Simple Stupid, cerchiamo di mantenere il più semplice possibile i binari installati sul nostro sistema. Certo, compilare monoliticamente o a moduli dinamici tutte le funzioni aggiuntive di Apache può risultare comodo: prima o poi potrebbero servire e non bisogna nemmeno ricompilare. Per una maggiore sicurezza, però, è meglio non avere in giro funzionalità che non vengono utilizzate, magari lasciate attivate per una dimenticanza: meglio non compilare nemmeno ciò che non serve. Già, ma cosa serve? Quali sono i moduli di base, il minimo indispensabile per avere un server web funzionale? Ecco quale è l’insieme minimo di moduli da installare per poter servire pagine senza troppi fronzoli:

  • httpd_core
    Modulo con le funzionalità di base, necessarie all’avvio di Apache;

  • mod_access
    Modulo che presiede alle direttive Allow, Deny e Order per l’accesso condizionato ai namespace;

  • mod_auth
    Modulo che offre l’autenticazione HTTP di base;

  • mod_dir
    Modulo che consente di implementare la direttiva DirectoryIndex, per indicare il file index di una directory;

  • mod_log_config
    Modulo per l’mplementazione delle funzioni di logging;

  • mod_mime
    Gestisce i set di caratteri l’encoding dei contenuti, il linguaggio predefinito delle pagine da servire e i tipi MIME dei documenti e altro ancora. Insomma, gestisce tutte le meta informazioni riguardanti le pagine servite.

Da disabilitare assolutamente, se non utilizzati:

  • mod_auto_index
    Consente di visualizzare il contenuto di una directory priva di file di indice;
  • mod_info
    Fornisce una lista di informazioni sul server, sui moduli compilati e sulle direttive di configurazione.

Conclusioni

Per ora abbiamo finito. Siamo arrivati fino alla configurazione dei sorgenti e compilazione del server. Nel prossimo articolo, approfondiremo quelle direttive di configurazione di Apache, che ci consentiranno di applicare delle direttive sufficientemente restrittive per limitare ragionevolmente la maggior parte degli attacchi più triviali.
Una volta configurato in maniera sicura il nostro server, lo sbatteremo in cella, in una chroot jail, dal quale un eventuale aggressore non uscirà molto facilmente.

GeekSquare – Top of the week

Zarrelli il domenica, 29 Gennaio, 2006

  • Arriva la fotocamera da 39 megapixel – Hasselblad annuncia una nuova fotocamera e due dorsi, basati sul suo CCD da ben 39 megapixel di recente introduzione e sulla tecnologia DAP (Digital APO Correction), in grado di offrire colori incredibilmente naturali e una brillantezza e nitidezza senza precedenti…
  • Un C64 nel browser – Accogliamo con piacere questa fantastica rassegna di giochi del Commodore 64. Potrete gustare ancora una volta queste gemme del passato semplicemente utilizzando il vostro browser…
  • Il telefonino biometrico – Il Willcom WX310J di Japan Radio è il primo telefonino che non ha bisogno del PIN per garantire la sicurezza d’accesso al proprietario, il quale deve semplicemente poggiare sul display il polpastrello di cui ha ‘registrato’ inizialmente l’impronta…
  • Windows XP su MacTel – E’ iniziato un concorso che premierà il primo in grado di fornire, tramite email, istruzioni precise su come caricare sia XP che OS X sui nuovi computer di Apple. L’idea è di un texano, Colin Nederkoorn, che pare abbia dato vita al concorso, mettendo in gioco i primi 100 dollari di tasca sua e invitando chiunque a fare delle donazioni…
  • Mattoncini Lego per Memory Stick – Best Rubber Productions colpisce ancora: dopo il guscio in silicone per l’iPod e vari altri oggetti meno tecnologici ma altrettanto ‘gommosi’, propone una custodia per le famose memory card di Sony cui quasi nessuno potrà resistere, visto il fascino esercitato dai mattoncini Lego…
  • Opera 8.5 beta per Windows Mobile – Finalmente un’alternativa al Pocket Explorer dei PDA che non sia NetFront: il browser Opera è disponibile infatti nella sua versione 8.5 beta per Windows Mobile 2003 e 2005 (ma a quanto pare funziona anche sui PocketPC precedenti) ed è basato sul programma corrispondente per desktop…
  • L’antivirus per gli umani – E’ un incrocio fra un umidificatore e uno ionizzatore, ma secondo la casa produttrice l’utilizzo di un ‘sistema disinfettante a base di acqua alfa-elettrolitica’ dovrebbe ridurre notevolmente la presenza di virus che si trasmettono per via aerea…
  • Nasce Blognews24.it, il MagBloig – Ops non ve l’avevamo ancora detto…ieri è nato Blognews24.it, un MagBloid, una nuova forma di comunicazione che trae il meglio dei Magazine tradizionali e dei Tabloid per darvi un’informazione internazionale a 360 gradi, 24 ore su 24…
  • La torcia salva-vita – E’ una luce di emergenza dotata di 12 LED luminosi e tre magneti per l’aggancio al tettuccio dell’auto, si può usare come martello per rompere i finestrini e anche come coltello per tagliare le cinture di sicurezza, nel caso si resti intrappolati nella vettura. Insomma, una vera e propria torcia salva-vita…
  • Da eTen un PDA-phone con GPS – Col nuovo G500 di eTen potrete organizzare le vostre informazioni personali, trasmettere e ricevere voce e dati e orientarvi con la navigazione satellitare. Manca purtroppo la funzione WiFi, ma forse sarebbe stato veramente troppo per il processore Samsung S3C2440 a 400MHz…

Nuova Etica, leggete in PDF, comprate se vi piace

Zarrelli il lunedì, 23 Gennaio, 2006

logo_nuova_etica_tiny.jpg

Sempre alla ricerca di qualche lettura, possibilmente senza spendere troppo. Ok, allora un salto sul sito di Nuova Etica vi consentirà di scaricare qualche libro in distribuzione gratuita, nel formato classico PDF.

Vi potete trovare testi di Narrativa/Teatro, Saggi, Poesia/Musica: dal romanzo La legge di Felham, di Michael Tobias, 288 pagine, all’opera teatrale Pipistrelli – Processo alle bestie, di Gennaro Francione, 78 pagine, passando per esperimenti di poesia in musica e fiabe, senza tralasciare la saggistica.
Come sono questi testi? Sinceramente non lo so, non li ho ancora letti. Scaricateli, leggeteli, se vi sono piaciuti potete anche ordinarne una copia stampata per pochi euro. La libertà di leggere l’avete, la volontà?

Geeksquare – Top of the week

Zarrelli il domenica, 22 Gennaio, 2006

  • Arriva Firefox per Mactel – La fondazione Mozilla ha annunciato che verso la fine di marzo sarà disponibile una versione di Firefox pienamente compatibile con i nuovi Mac Intel…
  • Il top del top del Malware – Stando a quanto riporta il blog di SiteAdvisor, scaricare wallpaper, suonerie e ammennicoli vari offerti “gratuitatente” su internet non è poi così sicuro. Tranquilli, però: dal sito di SiteAdvisor sarà possibile scaricare un plugin per IE e Firefox che vi dirà in tempo reale la “bontà” di un sito.
  • Le cartoline digitali usa e getta – Di cosa stiamo parlando? Del concept creato da Stuart Calvey, studente ventiduenne di design industriale della University of News South Wales, un involucro di cartone che racchiude uno schermo da 10 centimetri, una manciata di memoria digitale, una batteria e un obiettivo da 2 Mpx. Usa e getta…
  • Il vaccino su Pen Drive USB – I vostri dati, una volta caricati all’interno di questo innovativo Flash Drive, saranno al riparo da qualsiasi codice maligno, protetti da un meccanismo che aggiorna la lista dei virus ogni volta che la chiave viene inserita nella porta USB di un computer connesso a Internet…
  • Le novità della GPLv3, intervista a Stefano Maffulli – Per comprendere meglio le motivazioni che hanno portato al processo di revisione di una fra le più famose licenze, per coglierne le prime differenze con la precedente versione, per ricevere anche le impressioni a caldo dalla Conferenza di Boston, abbiamo posto a Stefano Maffulli, presidente della sezione italiana di Free Software Foundation Europe, alcune domande che ci aiutino a comprendere cosa sta cambiando, come e perché…
  • 100 applicazioni gratuite per XP – Lo sapevate che nel selvaggio web esisteva una raccolta di 100 programmi completamente gratuiti per Windows XP? Fatevi un giro su 100-download e scaricateli pure senza pietà…
  • Pandora, la radio che segue i tuoi gusti – Pandora RadioFate un salto su Pandora e attendete fino a quando l’applicazione a centro pagina si sarà caricata. Create una nuova radio e indicate un brano o un artista di riferimento per il canale. A questo punto, Pandora inizierà a proporvi una serie di canzoni che in un modo o nell’altro sono legate a quella iniziale, creando uno streaming continuo che cercherà di seguire i vostri interessi…
  • 200 siti di font, solo font, tanti font – Un elenco di oltre 200 luoghi della rete nei quali troverete font, molti font, davvero tanti font, gratuiti, shareware e commerciali. Parecchi sono freeware e quindi potrete utilizzarli senza problemi, altri, sicuramente, varranno il prezzo richiesto per utilizzarlo, tutti daranno qualcosa in più alle vostre pagine…
  • Lo scrigno USB con combinazione – Un’idea per San Valentino? Nascondete qualcosa di prezioso in questo mini-forziere e inviate la combinazione via SMS alla vostra ragazza, poi fatela sedere davanti al vostro PC e lanciate il programma che pilota il sistema di sicurezza…
  • Il biglietto del cinema nel cellulare – Mobile Box Office, il servizio lanciato negli USA da Mobile Relay che permette di scegliere con calma il film da andare a vedere e acquistarne il biglietto sotto forma di codice a barre, per mostrarlo in seguito all’ingresso del cinema e dirigersi senza battere ciglio verso la poltrona prenotata…

Le novità della GPLv3, intervista a Stefano Maffulli

Zarrelli il venerdì, 20 Gennaio, 2006

gplv3-conference-scalata.jpg
Stefano Maffulli, presidente della sezione italiana di Free Software Foundation Europe, Pablo Machón, coordinatore del team spagnolo di FSFE e Georg Greve, presidente di FSFE.

Ripropongo di seguito un’intervista che ho scritto per GeekSquare.

Tempo di revisione pubblica per la più famosa licenza per il software libero, quella GPL che dal 1991 è rimasta ferma alla versione 2. Quindici anni non sono pochi e lo sviluppo dei contenuti digitali impone un adeguamento che che la Free Software Foundation sta portando avanti con un progetto a due fasi.

Nel corso del 2005, Richard Stallman ed Eben Moglen, ovvero coloro che scrissero la prima e seconda versione della GPL, si sono messi al lavoro per creare una bozza che serva da base per una nuova Gnu General Public Licence e proprio in questi giorni, al Mit di Boston, il 16 e 17 Gennaio 2007 il “draft” è stato presentato alla prima conferenza internazionale dedicata alla GPLv3.

Il secondo passo di questo processo di revisione inizia proprio ora, con il rendere pubblica la nuova bozza e immetterla in un processo di revisione aperto a tutti, nel quale chiunque potrà contribuire allo sviluppo del documento finale che porterà alla definizione della nuova GPL.

Per comprendere meglio le motivazioni che hanno portato al processo di revisione di una fra le più famose licenze, per coglierne le prime differenze con la precedente versione, per ricevere anche le impressioni a caldo dalla Conferenza di Boston, abbiamo posto a Stefano Maffulli, presidente della sezione italiana di Free Software Foundation Europe, alcune domande che ci aiutino a comprendere cosa sta cambiando, come e perché.

Visto che sei alla conferenza di lancio della GPL versione 3, approfittiamone per qualche impressione di prima mano. Quale aria si respira alla conferenza, aspettative, timori?

Siamo al MIT, a Boston, a occhio e croce un centinaio di persone sono arrivate un po’ da tutto il mondo. L’aria la definirei amichevole, rilassata e curiosa. Stallman ha sintetizzato efficacemente lo scopo di questa revisione: la libertà di usare, studiare, modificare e distribuire software è minacciata dall’involuzione dei sistemi legali e dall’introduzione di misure tecnologiche volte a limitare le libertà degli utenti di software. In pratica, Stallman ha fatto riferimento alla larga diffusione dei brevetti software (che nel 1991 erano appena stati introdotti solo in USA e ora, in varie forme, sono diffusi quasi globalmente) e all’introduzione dei Digital Restrictions Management (DRM) in vari settori.

Lo spirito con cui FSF affronta la revisione della licenza è quello originario del MIT degli anni ’80: la protezione delle libertà degli
utenti di scrivere software come preferiscono. Il meccanismo principale della GNU GPL, il copyleft, è essenziale oggi come nel 1991 per impedire che il patrimonio di software disponibile finisca nelle tasche di uno solo.

Cerchiamo di chiarire in pochi punti essenziali quali sono i punti fondamentali di questa nuova versione della GPL. Cosa la caratterizza?

Credo che questa prima bozza contenga 4 punti essenziali rispetto alla GPLv2.

  1. Non fare danni. Ovvero, non indebolire le libertà concesse dal software libero;
  2. Affrontare le minacce legali e tecniche. Il motivo principale per la revisione della GPL è proprio il mutamento delle condizioni legali a contorno della tecnologia. I brevetti software si sono diffusi, come purtroppo la FSF aveva previsto negli anni ’90. Inoltre, leggi come il Digital Millenium Copyright Act (DMCA) e il corrispondente europeo European Union Copyright Directive (EUCD) mettono a rischio lo sviluppo di software libero. I sistemi DRM si incastrano perfettamente in questo nuovo ambiente legale e pertanto la FSF ha ritenuto giunto il momento di rivedere la GPL e prevedere un antidoto a questi problemi. Ci sono due nuovi punti nella licenza che iniziano ad affrontare il problema. In particolare, i DRM sono citati nella sezione 1, 1. Source Code, e nella sezione 3,
    3. Digital Restrictions Management, della bozza in discussione, mentre il problema brevetti è affrontato dalla clausola di rappresaglia, nella sezione 7.c e nella sezione 11.;
  3. Aumentare la compatibilità. Uno dei problemi della comunità del software libero è la proliferazione di licenze, spesso incompatibili tra di loro. L’incompatibilità è problematica perché limita la circolazione del codice tra vari progetti. Per questo la prima bozza della licenza ha una sezione dedicata ad aumentare la compatibilità con altre licenze;
  4. Globalizzare la licenza. Alcuni dei termini usati nella v2, come ‘distribution’, assumono un significato diverso in distinti sistemi legali. La bozza di GPLv3 usa termini diversi dandone la definizione all’inizio, parlando per esempio di ‘propagation’ che è un termine
    neutrale e lascia spazio alla localizzazione della licenza in altre lingue e sistemi legali, qualora si rendesse necessario.

Rispetto alla versione GPL 2, quali sono i punti di differenza, a quali nuove esigenze si è dato ascolto?

Rispetto a GPLv2 ci sono due esigenze difficili da conciliare: affrontare i problemi menzionati prima e chiarire i punti della v2 che in passato hanno dato spazio a troppe interpretazioni discordanti.

La revisione di una licenza è sempre un evento di rilevanza non indifferente, il tentativo di dare una risposta non solo a nuove esigenze ma anche a pressioni ambientali, sociali ed economiche. Quale è lo scenario legato al mondo economico, a quello dei diritti digitali, a quello sociale, che ha spinto a una revisione della GPL?

Posso dire che qui sono presenti tutti i rappresentanti delle maggiori aziende di software mondiale, da Intel a Sun a IBM a Google passando per tante altre. L’interesse intorno a questo processo di revisione della licenza è alto.

Chiariamo un punto: esiste una dimensione “economica” nel software libero? Il motivo ricorrente, che vede il compenso spostarsi dal bene, il codice, al servizio, l’implementazione e la personalizzazione, è un modello valido per descrivere questa dimensione o è limitativo?

Direi che la risposta può stare nelle aziende che sono venute qui a sentire cosa abbiamo da dire 🙂

Annunciare una nuova revisione è un punto di svolta, ci si lascia alle spalle qualcosa e si fanno dei buoni propositi per il futuro o, meglio, dei progetti concreti di azione. Dove vogliamo andare, domani?

Stiamo andando verso una società digitale dove sono garantiti tutti i diritti presenti in una società non-digitale. Il software governa le interazioni tra esseri umani nel mondo digitale, pertanto non può essere posseduto da una singola entità. Tutte le FSF (USA, Europa, America Latina e India) sono impegnate a garantire che le libertà civili e le interazioni sociali restino libere nel futuro

Il dove vogliamo andare, in linea generale, lo abbiamo capito. Ma come arrivarci? Come la nuova versione della GPL recepirà le esigenze attuali e le attese per il futuro?

La licenza presentata oggi è solo una bozza di lavoro per iniziare una discussione globale che avverrà durante il 2006. Stallman e il consigliere legale Moglen hanno lavorato durante il 2005 per preparare questa prima bozza. Hanno anche definito un processo aperto e partecipato in modo che chiunque abbia interesse nella licenza GNU GPL possa mandare i suoi commenti e seguirne passo passo l’evoluzione.

Il processo di revisione è realizzato a strati: è stato realizzato un sistema di commenti basato sul web in cui chiunque è benvenuto a partecipare. I commenti verranno raccolti da ‘comitati’, discussi e valutati apertamente in liste di discussione. Alcuni commenti verranno scartati (e ne verrà data ragione), altri diventeranno ‘problemi/issue’ da risolvere da parte di Stallman e Moglen. Un sistema di issue tracking terrà traccia di tutti i problemi aperti. Stallman e Moglen prenderanno in carico i problemi e inseriranno le soluzioni nel testo della licenza, fornendo anche le argomentazioni per ognuna delle loro scelte. Il processo andrà avanti fino a che ci saranno problemi seri irrisolti.

Chiunque contribuisca al processo di completamento della GPLv3 con i suoi commenti potrà seguire passo per passo l’evoluzione del commento attraverso il lavoro dei comitati fino all’approvazione (o rifiuto) finale.