GnuPG
 Versioni Compatibili Tutte le versioni supportate di Debian |
 |
Questa guida è basata sui seguenti articoli presenti all'interno del numero 4 dell'e-zine di Debianizzati.org : |
Introduzione
GnuPG (Gnu Privacy Guard o, in breve, GPG) fa parte del progetto GNU e si pone come una alternativa completamente open a PGP. Inoltre è totalmente aderente allo standard OpenPGP per cui è compatibile con tutti i programmi che ne fanno uso.
GnuPG consente due operazioni distinte:
- Cifrare un dato
- Firmare un dato
A differenza di un sistema di cifratura a chiave simmetrica, in cui l'algoritmo di decodifica utilizza la stessa chiave privata per cifrare e decifrare i messaggi da proteggere, GnuPG utilizza un sistema a chiave asimmetrica in cui viene utilizzata una coppia di chiavi: pubblica e privata. Con la chiave pubblica del destinatario si cifra un messaggio. Il destinatario lo decifrerà con la propria chiave privata.
In maniera simile avviene il processo di firma di un dato (file di testo, file binario, email, etc.). Il mittente appone la propria firma di un dato utilizzando la propria chiave privata e il destinatario controllerà la firma attraverso la chiave pubblica del mittente.
Si tenga ben presente che:
- Le procedure di cifratura e firma sono distinte: si può scegliere di eseguire una, l'altra o entrambe. Ad esempio si può cifrare un dato senza firmarlo, firmare un dato e trasmetterlo in chiaro oppure cifrare e firmare contemporaneamente.
- La cifratura impedisce che una terza persona possa interpretare il dato (questo sarà conosciuto solo dal mittente e dal destinatario) mentre la firma garantisce che il destinatario possa essere certo dell'identità della persona che ha trasmesso un dato. In quest'ultimo caso, il dato potrà essere cifrato o meno: questo dipende dal grado di importanza che gli si assegna.
- La scelta di firmare e/o cifrare un dato dipende dalle persone che si trovano ai capi del canale comunicativo ma, soprattutto, dal tipo di canale, dalla natura dei dati e dal grado di "fiducia" che si attribuisce alla persona con cui si scambiano le informazioni.
Scegliete con cura e ponderazione tanto maggiori quanto più importanti sono i dati che volete trasmettere!
Questi concetti verranno ripresi ed ampliati nel corso della guida.
Installazione
Apriamo il nostro terminale e installiamo GnuPG. È sufficiente un:
# apt-get install gnupg
Creazione delle chiavi
Procediamo adesso con la creazione della chiavi.
Sempre da terminale, ad installazione completata ma come utente comune, digitiamo:
$ gpg --gen-key
per accedere ad un menù di scelta attraverso cui gpg ci chiederà alcune informazioni per generare le chiavi.
Scelta dell'algoritmo
La prima richiesta da parte di gpg riguarda l'algoritmo (o gli algoritmi) da utilizzare. Davanti a noi si presenteranno quattro opzioni:
Per favore scegli che tipo di chiave vuoi: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (firma solo) (4) RSA (firma solo)
Notare che con le opzioni (1) e (2) in realtà verranno create due coppie di chiavi:
- master keypair
- la coppia di chiavi principale che verrà utilizzata per creare firme digitali
- subordinate keypair
- la coppia di chiavi subordinata (spesso la troverete con il nome di subkey) utilizzata per cifrare i dati.
|
Nota La chiave pubblica e la chiave privata vengono create internamente da GnuPG in base a queste due coppie di chiavi. In particolare la chiave pubblica è rappresentata:
mentre la chiave privata è formata:
Nonostante la leggera complicazione della struttura, per comodità, si fa sempre riferimento ad un'unica coppia di chiavi: la chiave pubblica e la chiave privata. Si tenga presente, inoltre, che successivamente è possibile creare ulteriori chiavi subordinate sia per la firma che per la cifratura. |
Le opzioni sono:
- RSA and RSA (default)
- verrà creata una chiave principale per le firme digitali e una chiave secondaria per la cifratura; in entrambi i casi verrà utilizzato l'algoritmo RSA. Questa è la scelta di default.
- DSA and Elgamal
- verrà creata una chiave principale DSA per le firme digitali e una chiave Elgamal secondaria per la cifratura.
- RSA (firma solo)
- verrà creata solo la chiave principale RSA per le firme digitali.
- DSA (firma solo)
- verrà creata solo la chiave principale DSA per le firme digitali.
Le opzioni (3) e (4) sono utili se:
- Si vuole soltanto creare firme digitali e non si è interessati a cifrare i dati.
- Si vogliono creare successivamente una o più coppie di chiavi subordinate con diversa lunghezza o diversa data di scadenza rispetto alla coppia di chiavi principale.
Creare chiave principale e subordinata
Scegliamo l'opzione (1) per iniziare a creare chiavi RSA.
Per favore scegli che tipo di chiave vuoi: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (firma solo) (4) RSA (firma solo) Cosa scegli? 1
Lunghezza della chiave
La successiva domanda riguarda la lunghezza in bit della chiave da creare:
RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048)
il valore di default (2048 bit) può andare più che bene; ovviamente maggiore è la lunghezza, maggiore sarà la sicurezza ma i tempi di cifratura e decifrazione saranno più lunghi.
Sono ammessi tutti i valori tra 1024 e 4096, premendo [Invio] si accetta il consiglio di gpg per creare chiavi di 2048 bit.
Se non avete problemi di velocità computazionale o se, soprattutto, la sicurezza è un fattore assolutamente essenziale e preponderante, la scelta deve ricadere sulla massima lunghezza consentita: 4096 bit.
La lunghezza, una volta stabilita, non potrà più essere modificata.
Digitiamo "2048" (o premiamo semplicemente [Invio]) per accettare al scelta predefinita e proseguiamo.
Durata della chiave
Adesso ci verrà chiesto per quanti giorni la chiave deve valere: le opzioni sono molte e noi sceglieremo la numero 0, ovvero nessuna scadenza:
Per favore specifica per quanto tempo la chiave sarà valida. 0 = la chiave non scadrà <n> = la chiave scadrà dopo n giorni <n>w = la chiave scadrà dopo n settimane <n>m = la chiave scadrà dopo n mesi <n>y = la chiave scadrà dopo n anni Chiave valida per? (0) 0
Il sistema ci chiederà quindi di confermare la scelta effettuata:
Key does not expire at all Is this correct? (y/N) y
Premendo "invio", giungeremo alla compilazione dei dati che precede la creazione della chiave pubblica e di quella privata.
You need a user ID to identify your key; the software constructs the user ID from the Real Name, Comment and Email Address in this form: "Heinrich Heine (Der Dichter) !heinrichh@duesseldorf.de?"
Dovremo a questo punto inserire il nostro Nome e Cognome, un indirizzo email valido e un commento (facoltativo):
Nome e Cognome: Indirizzo di Email: Commento:
Una volta compilati i campi e data la conferma, ci verrà mostrato il riepilogo delle informazioni inserite con la possibilità di modificarle, di cancellarle o di accettarle:
Hai selezionato questo User Id: Modifica (N)ome, (C)ommento, (E)mail oppure (O)kay/(Q)uit?
Ci verrà chiesto di inserire una passphrase che servirà per la protezione della chiave.
Questo è un passaggio importante: bisogna cercare di scegliere una buona passphrase e di non dimenticarla.
Confermata la passphrase, comparirà una richiesta di esecuzione di altre operazioni per la generazione dei numeri primi (la creazione di RSA si basa proprio su questi numeri per aumentare l'entropia), per cui, quando leggeremo queste righe:
Dobbiamo generare un mucchio di byte casuali. È una buona idea eseguire qualche altra azione (scrivere sulla tastiera, muovere il mouse, usare i dischi) durante la generazione dei numeri primi; questo da al generatore di numeri casuali migliori possibilità di raccogliere abbastanza entropia.
riduciamo il terminale e cominciamo a fare qualsiasi altra cosa: aprire documenti, digitare lettere a caso, giocare e ascoltare musica. L'importante è far lavorare il processore: nel caso ciò non accadesse, sullo schermo comparirà un avviso:
Non ci sono abbastanza byte casuali disponibili. Per favore fai qualche altra cosa per dare all'OS la possibilità di raccogliere altra entropia! (Servono altri 284 byte)
proseguiamo a lavorare, e quando i byte saranno stati accumulati, il computer automaticamente genererà le chiavi.
A lavoro completato si otterrà un messaggio simile a questo:
gpg: /home/pincopallino/.gnupg/trustdb.gpg: creato il trustdb gpg: key 20ACD5A1 marked as ultimately trusted chiavi pubbliche e segrete create e firmate. gpg: controllo il trustdb gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u pub 1024R/20ACD5A1 2010-02-11 Key fingerprint = 10 gruppi da 4 cifre che comporranno la "key finger print" uid Nome Cognome () !email? sub 1024R/7DB807FC 2010-02-11
Le chiavi sono state create con successo!
|
|
Nota importante La scelta della passphrase è un passaggio fondamentale nel processo di creazione della coppia di chiavi. Chiunque dovesse riuscire ad impadronirsi della chiave privata dovrebbe riuscire ad oltrepassare la cifratura della chiave privata stessa. Una buona passphrase è quella facile da ricordare ma che altri difficilmente possono indovinare o violare tramite attacco brute force. Ecco perché essa dovrebbe essere lunga e costituita da un insieme di caratteri alfabetici (maiuscoli e minuscoli), caratteri speciali e numeri. |
Crittografia simmetrica
Questo sistema crittografico prevede l'utilizzo di una sola chiave per la cifratura e la decifrazione.
La sua affidabilità è basata esclusivamente sulla robustezza dell'algoritmo di cifratura (di solito DES - Data Encryption Standard -).
Facciamo un esempio pratico cifrando un messaggio presente nella nostra $HOME contenuto nel file "file-segreto.txt".
Prima di tutto leggiamo le chiavi presenti nel nostro keyring identificando i dati relativi a quella creata in precedenza:
$ gpg --list-keys /home/glider/.gnupg/pubring.gpg ------------------------------- pub 1024D/3231A5D0 2008-07-26 uid Pinco Pallino (Chiave crittografica di Pinco Pallino) <pinco.pallino@gmail.com> sub 2048g/3B74F97C 2008-07-26 ... [cut] ...
Procediamo quindi a cifrare il messaggio:
$ gpg -r pinco.pallino@gmail.com --symmetric --encrypt file-segreto.txt
verrà richiesto l'inserimento e la conferma di una passphrase da utilizzare al momento della decifrazione del messaggio e sarà generato il file "file-segreto.txt.gpg", ossia il file cifrato.
Per decifrarlo:
$ gpg -o file-decifrato.txt --decrypt file-segreto.txt.gpg
e dopo l'inserimento della passphrase scelta in precedenza si otterrà il file "file-decifrato.txt".
La debolezza di questo approccio risiede nella necessità di condivisione della chiave di cifratura.
Per questo motivo, oggi, è preferibile affidarsi alla crittografia asimmetrica che garantisce una sicurezza maggiore.
Crittografia asimmetrica
Immaginiamo di disporre di un lucchetto elettronico e di due chiavi che lo aprono: una "pubblica" e una "privata".
Metteremo a disposizione di tutti il lucchetto e la chiave pubblica, in modo tale che ogni persona che vorrà inviarci qualcosa possa chiuderla in un contenitore qualsiasi che sigillerà con il nostro lucchetto elettronico.
Una volta chiuso il tutto (ovvero, dopo aver cifrato il contenuto con PGP), il contenitore ci potrà essere inviato sicuri che nessuno, durante il tragitto, sia in condizione di aprirlo e leggerne il contenuto.
A prima vista, un messaggio cifrato è illeggibile. Anche possedendo la chiave pubblica è impossibile decifrarlo.
È la nostra chiave privata che ci permetterà di riportare in chiaro il messaggio ricevuto.
Possediamo già una coppia di chiavi, una pubblica da distribuire e una privata da tenere, è il caso di inserirle all'interno di file di testo.
La procedura è molto semplice:
$ gpg --export -a pinco.pallino@gmail.com ? chiavepubblica.txt
così facendo si esporta la chiave pubblica, contenuta nel keyring ed appartenente all'utente identificato da quella particolare email, in un file chiamato chiavepubblica.txt.
Procederemo in modo simile all'esportazione della chiave privata:
$ gpg --export-secret-key -a pinco.pallino@gmail.com ? chiaveprivata.txt
e la chiave verrà esportata in un file chiamato chiaveprivata.txt.
Se proviamo ad aprire il file chiavepubblica.txt ci si presenterà davanti un file di questo genere:
-----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.10 (GNU/Linux) mI0ES3PwoAEEAM38UqWKnbthn1RAIj0EeIBbMOFoJ/UKgL0IyQxVz6JlVcFmWXr4 WzFMp025A0MyeWPj+vwGw42TBqJnS1jwu3cCff1OxsMYuX/afSWYM2tD7ey1nIXt bLsJyr5Zy2YSOsM80KG77gBlLWJxX6YCjTG076plVI+PeyU2HuyuPdCFABEBAAG0 NUFuZHJlYSBQb3NzZW1hdG8gKHByb3ZhKSA8YW5kcmVhLnBvc3NlbWF0b0BnbWFp bC5jb20+iLgEEwECACIFAktz8KACGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheA AAoJELE9UXEgrNWhjnsEALJc+6TAVd6P/S7fFsnWHpPnMX0r1VYvtp8uMmr2wZNa BLJNY4MsgWAJDMwJbakzdL2DC8ThU9ydUTcBpw2OWQW/i8CAyUkS5GjJ1iQ40tLt WfPTbAcCIbkJuep7XkFOMMsV/nJKbFMySKUCii3KFtj7nllxLQRbyhSsRr9LJ9Mo ......................... ......................... -----END PGP PUBLIC KEY BLOCK-----
Questa è la chiave pubblica che potremo consegnare a chi vogliamo e che permetterà di comunicare in modo sicuro con noi.
Facciamo un esempio pratico.
Ipotizziamo che qualcuno voglia inviarci un file cifrato.
Questa persona dovrà aggiungere la nostra chiave pubblica al proprio keyring:
$ gpg --import chiavepubblica.txt
Se l'importazione è andata a buon fine, dando:
$ gpg --list-key
vedrà nella lista anche la nuova chiave appena aggiunta.
Per la cifratura proseguirà ripetendo i passaggi su indicati inserendo nel campo UID la nostra email.
Completata la cifratura, ci invierà il messaggio cifrato che noi potremo decifrare inserendo la nostra passphrase, visto che quel file è stato cifrato con la nostra chiave pubblica!
Repository e GPG
Per garantire che un determinato repository sia fidato, in Debian si utilizza una chiave di cifratura GPG.
L'autenticazione è di forma univoca, ovvero una chiave GPG può autenticare un solo repository. Per i repository ufficiali, l'acquisizione della chiave di cifratura è automatica, infatti non andiamo mai ad aggiungere una chiave GPG al primo avvio della nostra Debian, a meno che non usiamo già dal primo avvio repository non ufficiali. Ma se volessimo usare un repository non ufficiale che richiede l'autenticazione ed essa non viene fatta in automatico? Dobbiamo importare le chiavi GPG per questi repository non ufficiali. Prendiamo l'esempio di deb-multimedia
## DEB MULTIMEDIA deb http://www.deb-multimedia.org jessie main
apriamo con il nostro editor di testo il file /etc/apt/sources.list e aggiungiamo questo repository. Salviamo e chiudiamo e cominciamo con i comandi.
# apt-get update
alla fine dell'update troveremo però un WARNING di questo tipo:
W: Errore GPG: http://www.deb-multimedia.org jessie InRelease: Le seguenti firme non sono state verificate perché la chiave pubblica non è disponibile: NO_PUBKEY 07DC563D1F41B907
analizziamo bene questo avvertimento: il sistema ci comunica che non è stato possibile verificare la firma del repository perché manca della chiave pubblica di riferimento.
La chiave che il sistema cerca è 07DC563D1F41B907. Sono a questo punto possibili due strade:
- Si installa il pacchetto "deb-multimedia-keyring"
- Si importa la chiave pubblica da un keyserver
Seguiamo il secondo metodo per completezza, visto che il primo metodo è abbastanza banale.
Preleviamo dal keyserver predisposto la chiave pubblica e utilizziamo apt-key per aggiungerla al portachiavi utilizzato da apt per verificare la firma dei repository:
# apt-key adv --keyserver subkeys.pgp.net --recv-keys 07DC563D1F41B907
Fatto questo, daremo nuovamente l'update con:
# apt-get update
e se non otterremo altri Warning vorrà dire che avremo importato la chiave in modo corretto.
Saremo parimenti certi che, da quel momento in poi, i pacchetti scaricati proverranno da una fonte sicura.
Perchè?
Il meccanismo di funzionamento della "crittografia asimmetrica" dovrebbe ormai essere chiaro: la chiave pubblica (quella conosciuta da tutti) serve a cifrare un file, per leggere il quale sarà necessaria la chiave privata (che deve essere tenuta segreta).
È però possibile usare la chiave privata per "'firmare"' un file e non solo per decifrarlo: in questo caso, chiunque sia in possesso di chiave pubblica potrà verificare che quel file sia stato firmato da quella chiave privata.
Ogni repository Debian contiene un file Release che viene aggiornato ogni volta che un pacchetto dell'archivio cambia e che contiene anche i "checksum" di altri file sempre contenuti in quel repository. Tra questi ci sono i file "Packages.gz".
Questo uno stralcio del file Release presente nei repository di Debian Lenny:
Origin: Debian Label: Debian Suite: stable Version: 5.0.4 Codename: lenny Date: Fri, 29 Jan 2010 23:18:16 UTC Architectures: alpha amd64 arm armel hppa i386 ia64 mips mipsel powerpc s390 sparc Components: main contrib non-free Description: Debian 5.0.4 Released 29 January 2010 MD5Sum: 5a5774342de8498b6c39666a287277cb 13513135 Contents-powerpc.gz 31e526616dffa65cbd000aba82049fb8 13210302 Contents-armel.gz a663bc33ed6e79c0256053cd30226987 13157248 Contents-alpha.gz d8b6b3e5097edcda8d280211fa5df4ca 13824603 Contents-i386.gz ... [cut] ... dda6fb2fc2e6ed6d41a6a0786c05e5bd 24354793 main/binary-i386/Packages 56df8601bb6c9fc91e899e88cbd6fe3d 6724599 main/binary-i386/Packages.gz !------ 9e32cd68e56b8ae0120b2e278e5a30d3 5196154 main/binary-i386/Packages.bz2 6f8ee24cb11bb35bfff84442b5f23c02 95 main/binary-i386/Release ... [cut] ...
Ogni file "Packages.gz", parimenti, contiene un checksum per ogni pacchetto in esso listato.
Eccone uno stralcio:
... [cut] ... Package: 3dchess Priority: optional Section: games Installed-Size: 100 Maintainer: Debian Games Team !pkg-games-devel@lists.alioth.debian.org? Architecture: i386 Version: 0.8.1-15 Depends: libc6 (?= 2.7-1), libx11-6, libxext6, libxmu6, libxpm4, libxt6, " xaw3dg (?= 1.5+E-1) Filename: pool/main/3/3dchess/3dchess.0.8.1-15.i386.deb Size: 34526 MD5sum: 4605788bdc35ee2e7ff419162f86c126 !------------ SHA1: 27415ead5f8bf401d73bd9f0fb9ea24cd727e54e SHA256: e1231555d343e141fbd803998537032e4af78695d523a0e8f65b2f6f4d38226f Description: 3D chess for X11 3 dimensional Chess game for X11R6. There are three boards, stacked vertically; 96 pieces of which most are the traditional chess pieces with just a couple of additions; 26 possible directions in which to move. The AI isn't wonderful, but provides a challenging enough game to all but the most highly skilled players. Tag: game::board, game::board:chess, implemented-in::c, interface::x11, " role::program, uitoolkit::xlib, use::gameplaying, x11::application ... [cut] ...
Mediante il confronto del checksum relativo al file "Packages.gz" contenuto nel Release file e del checksum del file "Packages.gz" contenuto nei repository, apt capisce se la copia scaricata di "Package.gz" file è corretta.
Quando poi scarica un singolo pacchetto, apt esegue il check di questo con quanto contenuto nel file "Packages.gz".
La firma crittografica del file Release è costituita da un file chiamato "Release.gpg" che viene fornito insieme al file Release.
Ecco il contenuto di http://ftp.it.debian.org/debian/dists/lenny/Release.gpg:
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iQIcBAABAgAGBQJLY2zLAAoJEJqjjc1VvjAr6E0QAJMm3HWcrMd3GPUxQ/tThtNz PsIUH5Bkd5LwHGXnRntz/pF1eeQPZ9VvwTNc0q+AP5ZP21/q3kiTFBbaqTkqXsc0 QOiF2mKMI+tv4iJaLqMI/IBEAXqwyIdDGXzuyCG50RxajKmARb4Npab2OqSz/Dy3 IMROR9wy8tzPnCtyVnkOZ7I1Vz0AF5JQYBCCDscQJu4O7i6t5itqkgF0vA/FvXJ2 GHOQPSAVOAMhd1vudVjn9bu5mP6cAT6wQoJKa/uNs5pRlotC2qN4unZKleZ2NHvU 9E7pVleKb1ND07dFPQZjDdT7Ir7B4J2Ma7yHXn8nFdPRrOHb0/fXBC5js0XgenHH ZASRQeZnjVh8PRAZDU47bhF9DIsaxnbds0DMMLFhMDQM2vGjQlTcWRoEPm1QMLv+ ttL7aD4rrq/S413cKodqaR9TnuXjydNoja8Od/cgtH9VvMKVtBbPdhjn749Fx5Hw b3fnwmzTbgguzsleRyF9/fJIBSuVc9TQH42GmCa7OsCB7wRHlOEdyj/4FtFfP37R 0gYTVQeeV5l9wP/cun3boWyhGSg2cXwhPKFU+I7cDW2TobQ3I/eUrodeyr/ikrPe iLqGsUXBIWmlAC7NGUBrITQw6rouc82qnDSKR+RLPBuXZeEVRy95d+LI+CvPa0sr TiHtlcssVR+1v/d1G9Qk =/CSh -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAktjbk0ACgkQTScNBvQlhOYVJgCgg1ry+a9GkDe5EDGy8M5ReE64 /TIAn1WqrgX49oOr6RVLXil2roYhCaX/ =003L -----END PGP SIGNATURE-----
Se apt non riesce a scaricare Release.gpg o se la firma non è verificata, avvisa che il "Packages.gz" al quale il file Release fa riferimento (e ovviamente tutti i file in esso listati) provengono da una fonte non verificata.
Il meccanismo di sicurezza si basa sulla verifica dell'esistenza e della validità di Release.gpg, validità accertata eseguendo il controllo di quella firma.
Per eseguire tale controllo, apt deve conoscere la chiave pubblica della persona che l'ha firmato (come detto la firma avviene per mezzo della propria chiave privata).
Tali chiavi pubbliche sono contenute nel keyring /etc/apt/trusted.gpg:
# apt-key list /etc/apt/trusted.gpg -------------------- pub 1024D/6070D3A1 2006-11-20 [expired: 2009-07-01] uid Debian Archive Automatic Signing Key (4.0/etch) " !ftpmaster@debian.org? pub 1024D/ADB11277 2006-09-17 uid Etch Stable Release Key !debian-release@lists.debian.org? pub 1024D/BBE55AB3 2007-03-31 [expired: 2010-03-30] uid Debian-Volatile Archive Automatic Signing Key (4.0/etch) pub 1024D/F42584E6 2008-04-06 [expires: 2012-05-15] uid Lenny Stable Release Key !debian-release@lists.debian.org? ... [cut] ...
È questa, per concludere, la ratio del funzionamento di GPG: una "catena di fiducia".
Le chiavi, firmate e gestite come appena esposto, sono gli unici veri garanti dell'affidabilità del repository.
Buon GPG a tutti!
| Guida scritta da: Greyfox |  Debianized 40%
|
| Estesa da: | |
| Verificata da: | |
|
Verificare ed estendere la guida | Cos'è una guida Debianized | |