<chapt>Infrastrutture per la sicurezza in Debian




<sect id="debian-sec-team">Il Team Debian per la Sicurezza

<p>L'aspetto sicurezza nella distribuzione <em>stable</em> viene 
trattato da un gruppo di persone - il Security Team, composto da 
cinque membri e due segretari - che seguono i problemi di 
vulnerabilità dell'ambiente software, partecipando a 
forum come bugtraq o vuln-dev e che poi stabiliscono se la 
distribuzione <em>stable</em> ne sia interessata.

<p>Quando i problemi non sono specifici solo di Debian, il Security Team 
è anche un punto di riferimento per quei problemi che potrebbero interessare 
più distributori e la cui disamina sia coordinata da sviluppatori di versioni 
ancora in fase progettuale o da organizzazioni come il 
<url id="http://www.cert.org" name="CERT">. 
Potete contattare il Security Team tramite:

<list>

<item><url id="mailto:team@security.debian.org" name="team@security.debian.org">, 
letta solo dai  membri del team stesso;
<item><url id="mailto:security@debian.org" name="security@debian.org">
letta da tutti gli sviluppatori di Debian, oltre che dai membri del team. 
Le lettere spedite a questo indirizzo non vengono pubblicate in Internet, 
non essendo questa una mailing list pubblica.

</list>

<p>Le informazioni sensibili vanno spedite al primo indirizzo e in alcuni casi, 
sottoposte a cifratura con la chiave Debian per il contatto sicuro 
(Debian Security Contact key, ID della chiave con ID 363CCD95).

<p>Una volta che la segnalazione di un possibile problema arriva al Security 
Team, questo cercherà di scoprire se la distribuzione <em>stable</em> ne sia
interessata e in tal caso, verrà elaborata una correzione per il codice 
sorgente di base. Questa correzione, a volte, include la rielaborazione di 
qualche adattamento progettuale (creato, di solito, per versioni successive a 
quella attualmente in distribuzione). Dopo un controllo sulla correzione, 
nuovi pacchetti vengono preparati e pubblicati sul sito 
<url id="security-master.debian.org">, in modo da essere disponibili tramite 
<prgn>apt</prgn> (vedete <ref id="security-update">). 
Allo stesso tempo, viene pubblicato sul sito e spedito alle 
mailing list pubbliche (comprese bugtraq e 
<url id="lists.debian.org/debian-security-announce" name="debian-security-announce">) 
un DSA (<em>Debian Security Advisory</em> - avviso per la sicurezza in Debian).

<p>Potete trovare altre "risposte a domande frequenti" in 
<ref id="debian-sec-team-faq">.


<sect id="dsa">Avvisi di sicurezza Debian

<p>Gli avvisi di sicurezza Debian (DSA)
vengono emessi ogni volta che viene scoperta una
vulnerabilità di sicurezza relativa ad un pacchetto Debian. Questi avvisi,
firmati da un membro del Security Team, includono informazioni sulla
versione colpita ed indicano dove scaricare gli aggiornamenti ed il loro 
MD5 sums. Le informazioni sono:

<list>

<item>Numero di versione della correzione.
<item>Tipo di problema.
<item>Se la vulnerabilità è sfruttabile da remoto o solo localmente.
<item>Breve descrizione del pacchetto.
<item>Descrizione del problema.
<item>Descrizione dell'exploit.
<item>Descrizione della correzione.

</list>

<p>Gli avvisi di sicurezza (DSA) vengono pubblicati sia sulla pagina 
<url id="http://www.debian.org/" name="principale del sito Debian">
che nelle <url id="http://www.debian.org/security/" 
name="pagine dedicate alla sicurezza in Debian">. Di solito questo 
non avviene simultaneamente alla notizia della scoperta dell'avviso 
perché il sito viene aggiornato ogni quattro ore e quindi gli 
avvisi stessi potrebbero non essere immediatamente visibili, 
pertanto il canale preferenziale per essere aggiornati 
tempestivamente è la mailing list debian-security-announce.

<p>Gli utenti interessati possono comunque (e questo viene fatto in alcuni
portali relativi a Debian) utilizzare il canale RDF per scaricare 
automaticamente gli avvisi di sicurezza sul loro desktop. Alcune 
applicazioni, come <prgn>Evolution</prgn> (un client e-mail ed assistente 
per informazioni personali) e <prgn>Multiticker</prgn> (un'applet
di GNOME), possono essere usate per reperire gli avvisi automaticamente. Il
canale RDF è disponibile su <url id="http://www.debian.org/security/dsa.rdf">.

<p>I DSA pubblicati sul sito potrebbero essere aggiornati dopo
essere stati spediti alle mailing-list pubbliche. Un aggiornamento 
tipico è aggiungere riferimenti incrociati ai database delle 
vulnerabilità di sicurezza.

Inoltre, le traduzioni<footnote>
          Le traduzioni sono disponibili in una decina 
          di lingue diverse.
</footnote> 
dei DSA non vengono spedite alle mailing list di sicurezza ma 
incluse direttamente nel sito.





<sect1 id="crossreference">Riferimenti incrociati sulle vulnerabilità

<p>Debian fornisce una <url
id="http://www.debian.org/security/crossreferences"
name="tabella completa di riferimenti incrociati"> che include tutti 
i riferimenti disponibili per tutti gli avvisi pubblicati dal 1998.
Questa tabella viene fornita per completare la 
<url id="http://cve.mitre.org/cve/refs/refmap/source-DEBIAN.html"
name="mappa di riferimento disponibile presso il CVE">.

<p>Potrete notare che questa tabella fornisce riferimenti a database 
di sicurezza come <url id="http://www.securityfocus.com/bid"
name="Bugtraq">, <url id="http://www.cert.org/advisories/" 
name="CERT/CC Advisories"> e <url id="http://www.kb.cert.org/vuls" 
name="US-CERT Vulnerability Notes Database"> come anche per i nomi 
CVE (vedete sotto). Questi riferimenti vengono forniti solo per 
comodità, ma solo i riferimenti CVE vengono periodicamente rivisti 
ed inclusi. Questa funzionalità è stata aggiunta al sito nel giugno 
2002.

<p>Uno dei vantaggi dell'aggiungere riferimenti incrociati a questi 
database di vulnerabilità è che:

<list>

<item>Rende agli utenti Debian più facile vedere e tenere traccia 
di quali avvisi pubblicati sono già stati coperti da Debian.

<item>Gli amministratori di sistema possono imparare di più sulle vulnerabilità 
ed il loro impatto seguendo i riferimenti incrociati.

<item>Queste informazioni possono essere usate per fare controlli incrociati con
l'output degli scanner di vulnerabilità che includono riferimenti a CVE per
rimuovere falsi allarmi (vedete in <ref id="vulnasses-false-positive">).

</list>





<sect1 id="cve-compatible">Compatibilità con CVE

<p>I Debian Security Advisories sono stati <url
id="http://www.debian.org/security/CVE-certificate.jpg"
name="dichiarati compatibili con CVE"><footnote>
          La piena <url
          id="http://cve.mitre.org/compatible/questionnaires/14.html"
          name="funzionalità, con relativa descrizione">, è
          disponibile presso CVE.
</footnote>
dal 24 febbraio 2004.

<p>Gli sviluppatori Debian capiscono la necessità di fornire 
informazioni accurate ed aggiornate sullo stato della sicurezza 
della distribuzione Debian, permettendo agli utenti di gestire 
i rischi associati con le nuove vulnerabilità della sicurezza.
CVE ci permette di fornire riferimenti standardizzati che 
permettono agli utenti di sviluppare un processo di
<url id="http://www.cve.mitre.org/compatible/enterprise.html"
name="gestione della sicurezza con CVE abilitato">.

<p>Il progetto <url id="http://cve.mitre.org" name="Common
Vulnerabilities and Exposures (CVE)"> viene mantenuto dalla MITRE
Corporation e fornisce un elenco standardizzato per le
vulnerabilità ed i problemi di sicurezza.

<p>Debian crede che fornire agli utenti informazioni aggiuntive 
relative alle questioni di sicurezza della distribuzione Debian 
sia estremamente importante. L'inclusione dei nomi CVE negli avvisi 
aiuta gli utenti ad associare delle generiche vulnerabilità con gli 
aggiornamenti Debian, il che riduce il tempo necessario per 
gestire le vulnerabilità che affliggono i nostri utenti. Inoltre, 
facilita la gestione della sicurezza in un ambiente dove strumenti 
di sicurezza con CVE abilitato - come sistemi di rilevamento 
d'intrusione su rete o su di un host, o strumenti per la valutazione 
di vulnerabilità - sono già in uso indipendentemente dal fatto che
siano basati sulla distribuzione Debian.


<p>Debian ha cominciato ad aggiungere i nomi CVE ai DSA nel giugno 
2002 ed ora li fornisce per tutti i DSA rilasciati dal settembre 
1998, in seguito a un processo di revisione cominciato nell'agosto 
2002. Tutti questi avvisi possono essere recuperati sul sito web 
di Debian ed i nuovi annunci riferiti alle nuove vulnerabilità
contengono i nomi CVE se disponibili al momento del loro rilascio. 
Gli avvisi associati ad un nome CVE possono essere ricercati 
direttamente attraverso il <url id="http://search.debian.org/" 
name="motore di ricerca">.

<p>Gli utenti che vogliono cercare un particolare nome CVE possono 
usare il motore di ricerca disponibile alla pagina debian.org per 
recuperare gli avvisi disponibili (in inglese e tradotti in altre 
lingue) associati ad un nome CVE. Può essere fatta una ricerca per 
un nome specifico (come advisory <url
id="http://search.debian.org/?q=advisory+%22CAN-2002-0001%22&amp;ps=50&amp;o=1&amp;m=all"
name="CAN-2002-0001">) o per un nome parziale (come tutti i 
candidati 2002 inclusi nella ricerca per <url
id="http://search.debian.org/?q=advisory+%22CAN-2002%22&amp;ps=50&amp;o=1&amp;m=all"
name="CAN-2002">). &Egrave; da notare che si deve inserire la parola
"advisory" con il nome CVE, allo scopo di recuperare solo gli avvisi 
di sicurezza.

<p>In alcuni casi potreste non trovare un dato nome CVE tra gli 
avvisi pubblicati, per esempio perché:

<list>
   <item> Non ci sono prodotti Debian affetti da quella specifica 
          vulnerabilità.
   <item> Non c'è ancora un avviso che copre quella vulnerabilità 
          (il problema di sicurezza potrebbe essere stato riportato 
          come <url 
          id="http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=security"
          name="bug di sicurezza"> ma non è ancora stata caricata o 
          collaudata un'apposita patch).
   <item> Un avviso è stato pubblicato prima che il nome CVE sia
          stato assegnato ad una data vulnerabilità (cercate un
          aggiornamento sul sito web).
</list>







<sect>La costruzione dell'infrastruttura di sicurezza in Debian


<p>Poiché Debian supporta attualmente un gran numero di
architetture, gli amministratori a volte si sorprendono se una
determinata architettura impiega più tempo per ricevere gli
aggiornamenti per la sicurezza rispetto ad un'altra. &Egrave; 
un dato di fatto, tranne in rare circostanze, che gli 
aggiornamenti siano disponibili per tutte le architetture allo 
stesso tempo.

<p>In precedenza il lavoro di costruzione degli aggiornamenti di sicurezza
veniva fatto a mano, oggi non più (come Anthony Towns descrive in una 
<url id="http://lists.debian.org/debian-devel-announce/2002/debian-devel-announce-20+0206/msg00002.html" 
name="email"> inviata alla mailing list debian-devel-announce datata 8 giugno 2002).

<p>I pacchetti vengono aggiornati dal Security Team (in 
<url id="ftp://security-master.debian.org:/org/security.debian.org/queue/unchecked">  
o in <url id="ftp://security-master.debian.org/pub/SecurityUploadQueue">),
con una patch appropriata
viene verificata la firma entro quindici minuti dall'aggiornamento, una volta
fatto, vengono aggiunti alla lista degli autobuilder (che non eseguono 
più di un archivio al giorno). 
Comunque, i pacchetti vengono costruiti automaticamente
per <em>tutte</em> le architetture mezz'ora o un'ora circa dopo
l'aggiornamento. In ogni caso, gli aggiornamenti di sicurezza sono un po'
differenti dai normali aggiornamenti inviati dai manutentori dei pacchetti
poiché, in alcuni casi, prima di essere pubblicati devono aspettare di essere
collaudati più a fondo, o deve essere scritto un avviso, o hanno bisogno di una
settimana o più per evitare di pubblicare i problemi finché tutti i
distributori non hanno la concreta possibilità di correggerlo.

<p>L'archivio aggiornamenti di sicurezza funziona con la seguente procedura
(chiamata <em>"Autocostruzione-Accettata"</em>):

<list>

<item>Qualcuno scopre un problema di sicurezza.
<item>Qualcuno risolve il problema e comincia un aggiornamento su 
security-master.debian.org (questo <em>qualcuno</em> è solitamente 
un membro del Security Team ma può anche essere un manutentore 
di un pacchetto con una correzione appropriata che ha contattato il 
Security Team in precedenza). Il Changelog include un 
<em>testing-security</em> o <em>stable-security</em> come
distribuzione finale.
<item>L'aggiornamento viene controllato e verificato dal sistema 
Debian e spostato in coda/accettato e quindi notificato al sistema 
buildd. Ai file che si trovano qui accede il Security Team e 
(a volte indirettamente) il sistema buildd.
<item>Il sistema buildd, progettato tenendo anche conto dei 
problemi di sicurezza,  prende il pacchetto sorgente (con una 
priorità maggiore delle normali costruzioni di pacchetti), lo 
costruisce ed invia i log al Security Team.
<item>Il Security Team risponde ai log e i nuovi pacchetti 
costruiti vengono caricati in coda/non_verificata, dove vengono
controllati da un sistema Debian e spostati in in_coda/accettati.
<item>Quando il Security Team trova il pacchetto 
sorgente accettabile (ovvero, che è stato correttamente 
costruito per tutte le architetture supportate e che 
corregge i buchi di sicurezza senza introdurne di nuovi) 
lancia uno script che:

<list>
<item>Installa il pacchetto nell'archivio di sicurezza.
<item>Aggiorna i file <file>Packages</file>, <file>Sources</file> e 
<file>Release</file> di security.debian.org nel solito modo 
(<prgn>dpkg-scanpackages</prgn>, <prgn>dpkg-scansources</prgn> ...).
<item>Imposta un template dell'avviso che il Security Team ha finito 
il suo compito.
<item>Inoltra (facoltativamente) il pacchetto agli appropriati 
aggiornamenti proposed-updates così che possa venire incluso nel 
vero archivio il più presto possibile.

</list>

</list>

<p>Questa procedura, precedentemente fatta a mano, è stata collaudata 
ed immessa nello stadio di congelamento di Debian 3.0 woody (luglio 
2002). Grazie a questa infrastruttura, il Security Team è stato in 
grado di avere pacchetti aggiornati pronti per le uscite di Apache 
ed OpenSSH per tutte le architetture supportate (quasi venti), in 
meno di un giorno.


<sect1>Guida degli sviluppatori agli aggiornamenti sulla sicurezza


<p>Questa mail è stata inviata da Wichert Akkerman alla
<url id="http://lists.debian.org/debian-devel-announce/2002/debian-devel-announce-200206/msg00004.html" 
name="mailing list Debian-devel-announce"> per descrivere il 
comportamento degli sviluppatori Debian in relazione ai problemi di 
sicurezza nei loro pacchetti. &Egrave; stata pubblicata qui, sia a 
beneficio degli sviluppatori, che per gli utenti, al fine di 
comprendere meglio come la sicurezza viene gestita in Debian.

<p>FIXME: Notate che il riferimento aggiornato per queste 
informazioni è la 
<url id="http://www.debian.org/doc/manuals/developers-reference/ch-pkgs#bug-security" 
name="Debian Developer's Reference (Guida per gli sviluppatori Debian)">, 
questa sezione verrà rimossa nelle prossime uscite.


<sect2>Coordinarsi con il Security Team


<p>Se uno sviluppatore viene a conoscenza di un problema di sicurezza, in un suo
pacchetto o in quello di qualcun altro, dovrebbe sempre contattare il 
Security Team (presso team@security.debian.org). &Egrave; loro compito tenere 
traccia dei nuovi problemi di sicurezza, possono aiutare i manutentori 
con i problemi di sicurezza o risolverli, sono responsabili dell'invio degli 
avvisi di sicurezza e della manutenzione di security.debian.org.

<p>Notate che gli avvisi di sicurezza vengono effettuati solo per le 
distribuzioni rilasciate, non per quelle testing, unstable (vedete 
<ref id="sec-unstable">) o per le distribuzioni più datate (vedete 
<ref id="sec-older">).


<sect2>Venire a conoscenza di un problema di sicurezza


<p>Ci sono vari modi in cui uno sviluppatore può venire a 
conoscenza di un problema di sicurezza:

<list>
<item>Ne ha notizia da un forum pubblico (mailing list, website, etc.).
<item>Qualcuno archivia un bugreport (dovrebbe essere utilizzato 
o aggiunto dallo sviluppatore il tag <em>Security</em>).
<item>Qualcuno lo informa con una mail privata.
</list>

<p>Nei primi due casi l'informazione è pubblica ed è importante rimediare il più 
presto possibile. Nell'ultimo caso l'informazione potrebbe non essere pubblica
e in quel caso ci sono varie possibilità per trattare il problema:

<list>

<item>Se si tratta di un problema banale (come file temporanei non 
sicuri) non c'è necessità di tenere segreto il problema e potete 
realizzare una soluzione e rilasciarla.
<item>Se il problema è rilevante, (exploit remoti, possibilità di 
ottenere privilegi di root) è consigliabile condividere 
l'informazione con altri produttori e coordinare il rilascio. Il 
Security Team tiene i contatti con varie organizzazioni ed individui 
e può occuparsene.

</list>

<p>In ogni caso, se la persona che riporta il problema chiede di non 
rilasciare l'informazione deve essere rispettata la sua decisione, 
con l'ovvia eccezione di informare il Security Team (lo sviluppatore 
dovrebbe avvertire il Security Team che l'informazione non può essere 
resa nota).

<p>Notate che se è necessaria la segretezza, lo sviluppatore può 
anche non fornire un rimedio per unstable (o altro), poiché il log di
informazione delle modifiche per la unstable è di dominio pubblico.

<p>Ci sono due ragioni per rilasciare informazioni anche se la 
segretezza è richiesta/necessaria: il problema è noto da troppo 
tempo o l'informazione diventa pubblica.


<sect2>Creare un pacchetto


<p>La linea di condotta più importante quando si crea un nuovo 
pacchetto che corregge un problema di sicurezza è apportare il 
minor numero di modifiche possibili.
La gente fa affidamento su un determinato comportamento di un 
programma, una volta rilasciato, quindi ogni modifica fatta può
compromettere un sistema. Questo è vero soprattutto per le librerie: 
lo sviluppatore deve accertarsi di non aver cambiato l'API o l'ABI
con qualunque modifica, per quanto minima, possa aver apportato.

<p>Questo significa che passare ad una versione più recente non è
una buona soluzione; invece sarebbe giusto introdurre le modifiche
nella vecchia. Di solito i manutentori della versione recente sono 
disponibili se serve aiuto, altrimenti il Security Team di
Debian potrebbe dare una mano.

<p>Talvolta non è possibile introdurre aggiornamenti per la sicurezza 
in versioni precedenti, per esempio quando sarebbe necessario 
modificare o riscrivere gran parte del codice. In questo caso 
sarebbe necessario passare ad una nuova versione, ma questo
passaggio va coordinato prima con il Security Team.

<p>In relazione a questo c'è un altro aspetto da considerare: gli
sviluppatori devono testare le vostre modifiche. Se esiste un 
exploit, lo sviluppatore deve provare se effettivamente la versione
originale è vulnerabile e se quella modificata non lo è. 
Lo sviluppatore deve anche testare il pacchetto nell'uso normale, 
visto che a volte una correzione per la sicurezza può portare a 
malfunzionamenti nell'uso ordinario.

<p>Infine, gli sviluppatori devono tenere a mente alcuni dettagli tecnici:

<list>
<item>Ricordare di riferirsi alla distribuzione giusta nel file
debian/changelog. Nel caso di stable si fa riferimento
a stable-security mentre per testing a testing-security.
Non bisogna riferirsi a &lt;codename&gt;-proposed-updates.
<item>Controllare che il numero di versione sia giusto. Deve essere
maggiore di quello del pacchetto corrente ma minore di quello
relativo a distribuzioni successive. Nel caso di testing questo
vuol dire che il numero di versione dello stesso pacchetto in
sid deve essere maggiore. Se non esiste ancora il pacchetto
(magari perché testing e sid hanno la stessa versione) occorre
prima caricare la nuova versione in unstable.
<item>Non caricare solo il sorgente se il pacchetto si trova
in binary-all, altrimenti l'infrastruttura buildd non 
costruirà questi pacchetti.
<item>Quando compilate un pacchetto vi dovete accertare di aver 
compilato su di un sistema 'pulito', cioè che abbia installato solo 
i pacchetti della distribuzione per cui state costruendo il 
pacchetto. Se non avete un sistema 'pulito' potete provare ad usare 
una macchina di debian.org (vedete http://db.debian.org/machines.cgi)
o impostare un chroot (i pacchetti <package>pbuilder</package> 
e <package>debootstrap</package> possono essere utili in questo caso).

</list>


<sect2>Caricare in archivio gli aggiornamenti di sicurezza

<p>Dopo che uno sviluppatore ha creato e testato il nuovo pacchetto,
questo deve essere caricato in modo da poter essere disponibile
negli archivi. Gli aggiornamenti di sicurezza vanno caricati in
ftp://security-master.debian.org/pub/SecurityUploadQueue/.

<p>Una volta che l'aggiornamento di sicurezza è stato accettato, il
pacchetto viene automaticamente costruito per tutte le architetture
e conservato in modo che possa essere verificato dal Security Team.

<p>Solo il Security Team può accedere agli aggiornamenti che sono in
attesa di essere accettati o verificati. Questa procedura è
necessaria perché ci potrebbero essere delle correzioni a problemi
di sicurezza che non possono ancora essere rese note.

<p>Se un membro del Security Team accetta un pacchetto, questo
viene reso disponibile in security.debian.org, così come in
&lt;codename&gt;-proposed-updates, in ftp-master o nell'archivio non-US.


<sect2>Gli annunci sulla sicurezza

<p>Gli annunci sulla sicurezza vengono scritti e pubblicati dal 
Security Team. Tuttavia i manutentori possono contribuire fornendo
il testo da pubblicare (o una sua parte). Le informazioni
che devono essere contenute in un annuncio sulla sicurezza vengono
descritte in <ref id="dsa">.


<sect id="deb-pack-sign">Firma dei pacchetti in Debian

<p>Questa sezione poteva anche essere intitolata "come aggiornare 
in sicurezza il proprio sistema Debian GNU/Linux" e fondamentalmente 
merita una propria sezione perché è una parte importante della 
"infrastruttura di sicurezza". La firma dei pacchetti è una cosa da tenere
in considerazione, dal momento che impedisce la manomissione dei pacchetti 
distribuiti sui mirror e gli attacchi di tipo man-in-the-middle
sui download. L'aggiornamento automatico del software è una
caratteristica importante ma è altrettanto importante 
anche eliminare i rischi che quest'operazione possa permettere 
la distribuzione di trojan e la compromissione del sistema 
durante gli aggiornamenti<footnote>
Alcuni sistemi operativi sono stati affetti da problemi di
aggiornamento automatico, per esempio la 
<url id="http://www.cunap.com/~hardingr/projects/osx/exploit.html"
name="vulnerabilità del Software Update di Mac OS X">.

<p>
FIXME: probabilmente la vulnerabilità relativa alla gestione
delle catene di certificati di Internet Explorer ha un impatto
sugli aggiornamenti di sicurezza in Microsoft Windows.
</footnote>.

<p>Debian non fornisce pacchetti firmati ma fornisce un
meccanismo disponibile fin da Debian 4.0 (nome in codice
<em>etch</em>) per verificare l'integrità<footnote>
        In versioni precedenti, come nel caso di Debian 3.1, 
        <em>sarge</em>,  è possibile utilizzare questa funzionalità 
        usando versioni avanzate del sistema di gestione dei 
        pacchetti, presenti nelle versioni testing  e portate su 
        stable.
</footnote>
dei pacchetti scaricati. Per maggiori informazioni, vedete 
in <ref id="apt-0.6">.

<p>Questo problema viene discusso più approfonditamente nello 
<url id="http://www.cryptnet.net/fdp/crypto/strong_distro.html" 
name="Strong Distribution HOWTO"> di V. Alex Brennen.


<sect1>Lo schema proposto per il controllo della firma dei pacchetti


<p>L'attuale (non implementato) schema di controllo della firma dei
pacchetti usando <prgn>apt</prgn> è il seguente:

<list>
<item>Il file <file>Release</file> include la somma MD5 di Packages.gz
(che contiene le somme MD5 dei pacchetti) e verrà firmato. La firma 
è una delle fonti certe.
<item>Questo file <file>Release</file> firmato viene scaricato con 
'apt-get update' e conservato insieme a <file>Packages.gz</file>.
<item>Quando un pacchetto sta per essere installato, viene prima 
scaricato, successivamente viene generata la somma MD5.
<item>Il file <file>Release</file> firmato viene controllato (la 
firma è ok) e viene estratto da questo la somma MD5 per il file 
<file>Packages.gz</file>, il checksum di <file>Packages.gz</file> 
viene generato e (se ok) la somma MD5 del pacchetto scaricato viene 
calcolata direttamente da sé stesso.
<item>Se la somma MD5 del pacchetto scaricato è la stessa di quella 
nel file <file>Packages.gz</file> allora verrà installato, altrimenti
l'amministratore  verrà avvisato ed il pacchetto verrà lasciato
in cache (così l'amministratore potrà decidere se installarlo o
meno). Se il pacchetto non è in <file>Packages.gz</file> e 
l'amministratore ha configurato il sistema per installare solo 
pacchetti firmati non sarà nemmeno installabile.

</list>

<p>Seguendo la catena delle somme MD5 <prgn>apt</prgn> è in grado di 
verificare se un pacchetto proviene da una determinata distribuzione
rilasciata da Debian. Questo è meno flessibile che firmare ogni 
singolo pacchetto, uno ad uno, ma può essere combinato anche con 
questo schema (vedete più sotto).

<p>Questo schema è <url
id="http://lists.debian.org/debian-devel/2003/debian-devel-200312/msg01986.html" 
name="pienamente implementato"> in apt 0.6 ed è disponibile fin da 
Debian 4.0. Per maggiori informazioni vedete in <ref id="apt-0.6">. 
I pacchetti che forniscono un'interfaccia utente per apt devono 
essere modificati per adattarsi a questa nuova caratteristica; 
questo è il caso di <prgn>aptitude</prgn> che è stato 
<url id="http://lists.debian.org/debian-devel/2005/03/msg02641.html"
name="modificato"> per adattarsi a questo schema. Alcune tra le 
interfacce che al momento rispettano questa nuova caratteristica 
sono <prgn>aptitude</prgn> e <prgn>synaptic</prgn>.

<p>La firma dei pacchetti è stata discussa in debian per molto
tempo, per altre informazioni leggete:
<url id="http://www.debian.org/News/weekly/2001/8/"> e
<url id="http://www.debian.org/News/weekly/2000/11/">.






<sect1 id="apt-0.6">Apt sicuro

<p>Il rilascio 0.6 di apt, disponibile fin da Debian 4.0, 
<em>etch</em>, ed i successivi rilasci, include <em>apt-secure</em>
(conosciuto anche come <em>secure apt</em>), uno stumento che 
permette ad un amministratore di sistema di verificare l'integrità 
dei pacchetti scaricati attraverso lo schema precedente. Questo 
rilascio comprende lo strumento <prgn>apt-key</prgn> per aggiungere 
nuove chiavi al portachiavi di apt, che per definizione contiene 
solamente la chiave corrente usata per firmare l'archivio Debian.

<p>Questi cambi sono basati sulla patch per <prgn>apt</prgn> 
(disponibile nel <url 
id="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=203741" 
name="Bug #203741">) che fornisce questa implementazione.

<p>Apt sicuro funziona controllando la distribuzione attraverso il 
file <file>Release</file>, come discusso in 
<ref id="check-releases">. Di solito, questo processo è trasparente 
all'amministratore anche se è necessario un intervento ogni 
anno<footnote>
          Fino a quando non verrà sviluppato un processo 
          automatico.
</footnote>
per aggiungere la nuova chiave all'archivio quando vengono ruotati 
i log, per maggiori informazioni sui passi che un amministratore 
deve compiere vedete <ref id="secure-apt-add-key">.

<p>Questa funzionalità è ancora in sviluppo, se ritenete di aver
scoperto qualche bug, per favore, per prima cosa verificate di star 
usando l'ultima versione (visto che questo pacchetto potrebbe 
cambiare un po' prima di essere rilasciato definitivamente) e, se 
state proprio utilizzando l'ultima versione, inviate un bug al 
pacchetto <package>apt</package>.

<p>Potete trovare maggiori informazioni sulle 
<url id="http://wiki.debian.org/SecureApt" name="pagine del wiki"> 
e sulla documentazione ufficiale: 
<url id="http://www.enyo.de/fw/software/apt-secure/"
name="Migration to APT 0.6 (Migrazione ad APT 0.6)"> e 
<url id="http://www.syntaxpolice.org/apt-secure/" 
name="APT Signature Checking (Verifica delle Firme per APT)">.







<sect1 id="check-releases">Controllo di rilascio per 
                           ogni distribuzione

<p>Questa sezione descrive come il meccanismo di controllo del 
rilascio della distribuzione funzioni, fu scritto da Joey Hess 
ed è disponibile anche presso il 
<url id="http://wiki.debian.org/SecureApt" name="Wiki Debian">.


<sect2>Concetti di base

<p>Qui diamo alcuni concetti di base necessari per capire il resto 
di questa sezione.

<p>Un checksum è un metodo che consiste nel prendere un file e manipolarlo per 
tirarne fuori un numero di una lunghezza ragionevole che identifichi 
in maniera univoca il contenuto. Ciò è un po' più complicato di 
quanto possa sembrare, ed il tipo di checksum più usato, la somma 
MD5, è stato completamente violato.

<p>La crittografia a chiave pubblica è basata su una coppia di 
chiavi, una pubblica ed una privata. La chiave pubblica deve essere 
diffusa il più possibile; la chiave privata deve invece rimanere 
segreta. Chiunque possegga la chiave pubblica può cifrare un 
messaggio che possa essere letto solo da chi possiede la chiave 
privata corrispondente. &Egrave; anche possibile usare la chiave 
privata per firmare un file, ma non per cifrarlo. Se una chiave 
privata viene usata per firmare un file, chiunque in possesso della 
chiave pubblica corrispondente può verificare se il file è stato 
firmato da quella chiave. Nessuno che non possegga la chiave 
privata può creare una tale firma.

<p>Queste chiavi sono dei numeri abbastanza lunghi (da 1024 o 2048 
cifre binarie), e perché sia più semplice lavorarci, hanno un 
identificativo di chiave, che è un numero più corto, di 8 o 16 cifre 
binarie.

<p><prgn>gpg</prgn> è lo strumento usato nella versione sicura di apt 
per firmare i file e verificarne le firme.

<p><prgn>apt-key</prgn> è un programma che viene usato per gestire 
un portachiavi di chiavi gpg per apt sicuro. Il portachiavi viene 
mantenuto nel file <file>/etc/apt/trusted.gpg</file> (da non 
confondersi con file <file>/etc/apt/trustdb.gpg</file> sempre legato 
ad apt, ma non troppo interessante). <prgn>apt-key</prgn> può essere 
usato per mostrare le chiavi del portachiavi, per aggiungerne e per 
rimuoverne altre.

<sect2>Checksum di <file>Release</file>

<p>Un archivio Debian contiene un file <file>Release</file>, che 
viene aggiornato ogni volta che un pacchetto dell'archivio cambia. 
Tra l'altro, il file <file>Release</file> contiene le somme MD5 di 
altri file presenti nell'archivio. Un estratto di un file 
<file>Release</file> di esempio:

<example>
MD5Sum:
 6b05b392f792ba5a436d590c129de21f            3453 Packages
 1356479a23edda7a69f24eb8d6f4a14b            1131 Packages.gz
 2a5167881adc9ad1a8864f281b1eb959            1715 Sources
 88de3533bf6e054d1799f8e49b6aed8b             658 Sources.gz
</example>

<p>I file <file>Release</file> comprendono anche un checksum SHA-1, 
che sarà utile una volta che i checksum MD5 verranno completamente 
rotti, ad ogni modo apt per ora non li usa.

<p>Adesso, se guardiamo in un file <file>Packages</file>, troveremo 
diversi checksum MD5, uno per ogni pacchetto elencato. Ad esempio:

<example>
    Package: uqm
    Priority: optional
    ...
    Filename: unstable/uqm_0.4.0-1_i386.deb
    Size: 580558
    MD5sum: 864ec6157c1eea88acfef44d0f34d219
</example>

<p>Questi due checksum possono essere usati per verificare che si 
sia scaricata una versione corretta del file <file>Packages</file>, 
con un md5sum che corrisponde con quello del file <file>Release</file>. 
Inoltre, quando scaricate un singolo pacchetto, potete verificare il 
suo md5sum con quello contenuto nel file <file>Packages</file>. 
Se apt fallisce entrambi questi passi, abortisce.

<p>Nulla di questo è nuovo nella versione sicura di apt, ma ne 
fornisce le fondamenta. Notate che ad ogni modo c'è un file che apt 
non ha modo di verificare: il file <file>Release</file>. Questa 
versione sicura di apt ruota tutto attorno alla verifica del file 
<file>Release</file> prima di intraprendere qualunque azione, in modo 
che ci sia una catena ininterrotta di verifica, dal pacchetto che 
state per installare fino al al fornitore del pacchetto stesso.




<sect2>Verifica del file <file>Release</file> 

<p>Per verificare il file <file>Release</file>, viene aggiunta al 
file una firma gpg. Questa viene messa in un file chiamato 
<file>Release.gpg</file> che viene fornito assieme al file 
<file>Release</file>. Assomiglia a qualcosa del genere<footnote>
          Parlando tecnicamente, questa è una firma gpg ASCII.
</footnote>
, anche se di solito solo gpg guarda il suo contenuto:


<example>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBCqKO1nukh8wJbxY8RAsfHAJ9hu8oGNRAl2MSmP5+z2RZb6FJ8kACfWvEx
UBGPVc7jbHHsg78EhMBlV/U=
=x6og
-----END PGP SIGNATURE-----
</example>

<sect2>Verifica del file <file>Release.gpg</file> da parte di <prgn>apt</prgn>

<p>La versione sicura di Apt scarica sempre i file 
<file>Release.gpg</file> quando scarica i file <file>Release</file> e 
se non riesce a farlo, o se la firma non è valida, si lamenterà ed 
annoterà che il file <file>Packages</file> a cui il file 
<file>Release</file> punta, con tutti i pacchetti elencati al suo 
interno, provengono da una sorgente non fidata. Ecco a cosa somiglia 
un'operazione come <prgn>apt-get update</prgn>:

<example>
W: GPG error: http://ftp.us.debian.org testing Release: The following signatures
 couldn't be verified because the public key is not available: NO_PUBKEY 010908312D230C5F
</example>

<p>Notate che la seconda metà del numero "long" è l'identificativo 
della chiave che apt non conosce, e in questo caso è 2D230C5F.

<p>Se ignorerete l'avvertimento e tenterete di installare un 
pacchetto più avanti, apt avvertirà nuovamente:

<example>
WARNING: The following packages cannot be authenticated!
  libglib-perl libgtk2-perl
Install these packages without verification [y/N]?
</example>

<p>Se risponderete Y non avrete alcun modo di sapere se il file che
state per ricevere è il pacchetto che intendete installare o se è 
qualcos'altro che qualcuno può aver deciso di spedirvi avendolo 
preparato appositamente con all'interno una cattiva sorpresa, dopo 
aver intercettato la comunicazione verso il server<footnote>
          O abbia contraffatto il vostro DNS, o si stia fingendo il 
          server, o abbia rimpiazzato il file nel mirror che state 
          usando, etc..
</footnote>.

<p>Notate che potete disabilitare questi controlli eseguendo apt con 
l'opzione --allow-unauthenticated.

<p>Vale anche la pena notare che le nuove versioni dell'installatore 
Debian usano lo stesso meccanismo del file <file>Release</file> 
firmato durante il debootstrap del sistema base Debian, prima che apt 
sia disponibile. Perfino l'installer usa questo sistema per 
verificare pezzi di se stesso che scarica dalla rete. Inoltre, Debian 
attualmente non firma i suoi file <file>Release</file> nei CD; apt 
può essere comunque configurato per fidarsi sempre dei pacchetti dai 
CD così che questo non sia un grosso problema.

<sect2>Come dire ad apt di cosa fidarsi

<p>Quindi la sicurezza dell'intero sistema dipende dalla presenza di 
un file <file>Release.gpg</file>, che firma un file 
<file>Release</file> e da <prgn>apt</prgn> che verifica tale firma 
usando gpg. Per verificare la firma dovete conoscere la chiave 
pubblica del firmatario. Queste chiavi vengono conservate proprio nel 
portachiavi di apt (<file>/etc/apt/trusted.gpg</file>) e con la 
gestione delle chiavi fa il suo ingresso la versione sicura di apt.

<p>I sistemi Debian vengono configurati, in modo predefinito, con la 
chiave dell'archivio Debian nel portachiavi.

<example>
# apt-key list
/etc/apt/trusted.gpg
--------------------
pub   1024D/4F368D5D 2005-01-31 [expires: 2006-01-31]
uid                  Debian Archive Automatic Signing Key (2005) &lt;ftpmaster@debian.org&gt;
</example>

<p>In questo caso 4F368D5D è l'id della chiave e notate che tale 
chiave rimane valida solo per un anno. Debian cambia regolarmente 
queste chiavi come ultima misura di sicurezza nel caso in cui le 
chiavi vengano compromesse.

<p>Tale operazione farà si che <prgn>apt</prgn> si fidi dell'archivio 
Debian ufficiale, ma se aggiungete altri repository apt nel file 
<file>/etc/apt/sources.list</file>, dovrete anche aggiungere le 
chiavi di tali repository se volete che <prgn>apt</prgn> li consideri 
come fidati. Una volte in possesso della chiave e dopo che l'avrete 
verificata, dovrete semplicemente eseguire il comando 
<prgn>apt-key add file</prgn> per aggiungerla. La parte più complessa 
dell'operazione è sicuramente ottenere la chiave e verificarla. 




<sect2>Come ottenere la chiave di un repository

<p>Il pacchetto debian-archive-keyring viene usato per distribuire le 
chiavi tramite <prgn>apt</prgn>. Aggiornate questo pacchetto per 
aggiungere (o rimuovere) chiavi gpg relative all'archivio principale 
di Debian.

<p>Per quanto riguarda gli altri archivi, non esiste ancora un sito 
standard dove trovare le chiavi di un qualsiasi repository apt. Di 
solito la chiave viene messa sulla pagina web del repository o in un 
file nel repository stesso, ma non esiste uno standard ben definito e
potreste doverla cercare da soli.

<p>la chiave usata per firmare l'archivio principale Debian è 
<url id="http://ftp-master.debian.org/ziyi_key_2006.asc"> (sostituite 
2006 con l'anno attuale)<footnote>
          Il programma usato per la firma degli archivi sui server 
          Debian si chiama "ziyi", dal nome di <url
          id="http://en.wikipedia.org/wiki/Zhang_Ziyi" 
          name="un'attrice cinese">.
</footnote>.

<p>Lo stesso programma <prgn>gpg</prgn> ha una procedura standard 
per distribuire le chiavi, scaricando le chiavi da un server apposito 
ed aggiungendole al suo portachiavi. Per esempio:

<example>
$ gpg --keyserver pgpkeys.mit.edu --recv-key 2D230C5F
gpg: requesting key 2D230C5F from hkp server pgpkeys.mit.edu
gpg: key 2D230C5F: public key "Debian Archive Automatic Signing Key (2006) &lt;ftpm
aster@debian.org&gt;" imported
gpg: Total number processed: 1
gpg:               imported: 1
</example>

<p>Potete poi esportare tale chiave dal vostro portachiavi e fornirla 
al programma <prgn>apt-key</prgn>:

<example>
$ gpg -a --export 2D230C5F | sudo apt-key add -
gpg: no ultimately trusted keys found
OK
</example>

<p>L'avviso "gpg: no ultimately trusted keys found" indica che gpg 
non è stato configurato per dare fiducia indiscussa a una delle 
chiavi presenti nel vostro portachiavi. Il livello di fiducia nelle 
singole chiavi dipende dalla 
<url id="http://it.wikipedia.org/wiki/Web_of_trust" 
name="rete di fiducia"> usata da OpenPGP ed in questo caso potete 
ignorarlo. In una configurazione tipica, viene data fiducia 
indiscussa alla chiave dell'utente.




<sect2 id="secure-apt-add-key">Come aggiungere una chiave in maniera sicura

<p>Quando aggiungete una chiave al portachiavi di apt, state dicendo 
ad apt di considerare come fidato qualsiasi file firmato da quella 
chiave; in questa maniera sarete certi che apt non installerà nulla 
che non sia firmato da quella chiave o dalle altre nel portachiavi. 
Potreste obiettare, se siete abbastanza paranoici, che in tale 
maniera il problema è stato solo spostato e non risolto; ora invece 
di preoccuparvi se un certo pacchetto o un file <file>Release</file> 
è valido, potreste preoccuparvi che la chiave sia valida.  Il file 
summenzionato 
<url id="http://ftp-master.debian.org/ziyi_key_2006.asc"> è veramente 
la chiave utilizzata per firmare l'archivio Debian? 
Questo documento è attendibile? 

<p>Nel campo della sicurezza, la paranoia è un bene, ma rispondere 
alle suddette domande non è semplice. <prgn>gpg</prgn> usa il concetto 
della catena della fiducia: qualcuno di cui vi fidate firma la chiave 
di qualcun'altro, che a sua volta firma la chiave di una terza 
persona, etc.; alla fine uno degli anelli di questa catena firmerà la 
chiave dell'archivio Debian. Ancora una volta, se siete abbastanza 
paranoici, vorrete controllare che la chiave dell'archivio Debian sia 
firmata da una chiave di vostra fiducia, ossia da una chiave che fa 
parte di una catena di fiducia in cui uno dei partecipanti è una 
persona che conoscete personalmente. In tal caso, andate ad una 
conferenza tenuta dal progetto Debian oppure recatevi presso un LUG a 
voi vicino<footnote>
          Non tutte le chiavi dei repository apt sono firmate da 
          altre chiavi. Forse la persona che ha creato il repository 
          non ha un'altra chiave, o forse non ha ritenuto opportuno 
          firmare la chiave del repository apt con la propria chiave 
          personale. Per maggiori informazioni sulla creazione di una 
          chiave per un repository apt vedete in 
          <ref id="check-non-debian-releases">.
</footnote>.

<p>Se non siete così paranoici, potete fare quello che ritenete più 
opportuno ogni volta che usate un nuovo archivio di pacchetti e 
dovrete quindi aggiungere una chiave ad apt. Potreste inviare una 
email alla persona che vi ha inviato la chiave chiedendo conferma 
della bontà della chiave, o potreste semplicemente scaricare la 
chiave ed assumere che sia quella giusta. Il vantaggio principale 
di questa versione sicura di apt è  che, visto che ogni pacchetto 
viene firmato da una chiave, il problema dell'autenticità dei 
pacchetti si riduce al problema dell'autenticità della chiave che li 
firmano; perciò, potete scegliere il numero e la qualità dei 
controlli sull'autenticità della chiave a vostro piacimento.



<sect2>Verifica dell'integrità della chiave

<p>Potreste verificare, oltre alle firme, anche l'integrità della 
chiave. Solitamente l'integrità della chiave viene garantita da una 
funzione di hash con probabilità di collisione bassa o nulla. Potete 
trovare gli hash delle chiavi in vari modi, ovvero potete controllare 
il testo <url
id="http://debiansystem.info/readers/changes/547-ziyi-key-2006" 
name="The Debian System Book">, consultare gli sviluppatori Debian su 
IRC, leggere le mailing list dove vengono annunciate le modifiche delle 
chiavi usate per firmare gli archivi. Vi sono inoltre ancora altri 
metodi, per raggiungere lo scopo, come ad esempio questo: 

<example>
$ GET http://ftp-master.debian.org/ziyi_key_2006.asc | gpg --import
gpg: key 2D230C5F: public key "Debian Archive Automatic Signing Key (2006)
  &lt;ftpmaster&amp;debian.org&gt;" imported
gpg: Total number processed: 1
gpg:               imported: 1
$ gpg --check-sigs --fingerprint 2D230C5F
pub   1024D/2D230C5F 2006-01-03 [expires: 2007-02-07]
      Key fingerprint = 0847 50FC 01A6 D388 A643  D869 0109 0831 2D23 0C5F
uid   Debian Archive Automatic Signing Key (2006) &lt;ftpmaster@debian.org&gt;
sig!3        2D230C5F 2006-01-03  Debian Archive Automatic Signing Key
                                  (2006) &lt;ftpmaster@debian.org&gt;
sig!         2A4E3EAA 2006-01-03  Anthony Towns &lt;aj@azure.humbug.org.au&gt;
sig!         4F368D5D 2006-01-03  Debian Archive Automatic Signing Key
                                  (2005) &lt;ftpmaster@debian.org&gt;
sig!         29982E5A 2006-01-04  Steve Langasek &lt;vorlon@dodds.net&gt;
sig!         FD6645AB 2006-01-04  Ryan Murray &lt;rmurray@cyberhqz.com&gt;
sig!         AB2A91F5 2006-01-04  James Troup &lt;james@nocrew.org&gt;
</example>

e poi controllate la catena della fiducia che parte dalla vostra 
chiave (o comunque da una chiave di cui voi vi fidate, vedete in 
<ref id="deb-pack-sign">,  ) e arriva ad 
una delle chiavi usate per firmare la chiave dell'archivio. Se siete 
abbastanza paranoici potreste far sì che apt accetti la chiave come 
valida solo se tale catena esiste: 

<example>
$ gpg --export -a 2D230C5F | sudo apt-key add -
Ok
</example>

<p>Notate che la nuova chiave è firmata con la chiave precedente 
dell'archivio, pertanto teoricamente potreste limitarvi ad aggiungere 
un anello alla catena di fiducia costruita in precedenza.

<sect2>Rinnovo annuale delle chiavi degli archivi Debian

<p>Come summenzionato, la chiave utilizzata per firmare gli archivi 
Debian viene cambiata ogni anno, a gennaio. Poiché la versione sicura 
di apt è un programma giovane, i suoi sviluppatori non hanno ancora 
ben collaudato le procedure da seguire per il rinnovo della chiave e 
ci potrebbero essere dei passi da compiere ancora non ben definiti. 

<p>Nel gennaio 2006 il file <file>Release</file> venne firmato dalla 
nuova chiave ma, per evitare di danneggiare i sistemi che usavano 
ancora la chiave del 2005, tale file venne firmato anche dalla 
vecchia chiave. Si pensava che apt avrebbe considerato validi i file 
firmati da almeno una chiave che apt considerasse fidata, ma apt 
aveva un difetto per cui considerava validi solo i file firmati 
esclusivamente da chiavi che apt considerasse fidate. Questo difetto 
fu corretto nella versione 0.6.43.1. di apt. Si creò un po' di 
confusione anche sulla distribuzione della nuova chiave agli utenti 
che già usavano la versione sicura di apt; in un primo momento venne
distribuita sul sito web senza un annuncio specifico e senza che gli
utenti fossero in grado di verificarla; gli utenti furono costretti a 
scaricarla ed installarla a mano.

<p>Nel gennaio 2006, fu creata una nuova chiave per il 2006 e si 
cominciò a firmare con essa il file <file>Release</file>, ma per
cercare di non rompere la compatibilità con i sistemi che avevano
ancora la vecchia chiave del 2005, il file <file>Release</file>
venne firmato anche con quella vecchia. Per evitare confusione sul
miglior meccanismo di distribuzione per gli utenti che già avevano
sistemi che usavano la versione sicura di apt, fu introdotto il
pacchetto debian-archive-keyring, che gestisce gli aggiornamenti del
portachiavi di apt.


<sect2>Problemi noti sul controllo della versione

<p>Un problema non molto ovvio è che se l'orologio di sistema è 
sballato di molto, la versione sicura di apt non potrà funzionare. 
Se l'orologio segna una data del passato, ad esempio il 1999, 
apt se ne uscirà con un messaggio d'errore poco utile come 
questo:

<example>
W: GPG error: http://archive.progeny.com sid Release: Unknown error executing gpg
</example>

<p>In ogni caso <prgn>apt-key</prgn> renderà chiaro il problema:

<example>
gpg: key 2D230C5F was created 192324901 seconds in the future (time warp or clock problem)
gpg: key 2D230C5F was created 192324901 seconds in the future (time warp or clock problem)
pub   1024D/2D230C5F 2006-01-03
uid                  Debian Archive Automatic Signing Key (2006) &lt;ftpmaster@debian.org&gt;
</example>

<p>Se invece segna una data troppo distante nel futuro, apt 
considererà le chiavi come scadute.

<p>Un altro problema in cui vi potete imbattere usando testing o
unstable è che, se non avete eseguito recentemente
<prgn>apt-get update</prgn> prima di <prgn>apt-get install</prgn> su 
di un pacchetto che volete installare, apt potrebbe lamentarsi di 
non potersi autenticare (perché lo fa?).
<prgn>apt-get update</prgn> correggerà il problema.






<sect2 id="manual-check-releases">Controllare manualmente i rilasci della distribuzione

<p>Nel caso in cui vogliate aggiungere adesso i controlli di 
sicurezza aggiuntivi e non vogliate o possiate eseguire l'ultima 
versione di apt<footnote>
          O perché state usando la versione stabile, <em>sarge</em>, o
          una versione più vecchia o perché non volete usare l'ultima
          versione di apt, anche se apprezzeremmo molto che gli
          utenti la collaudassero.
</footnote>
, potete usare lo script qui sotto, fornito da Anthony Towns. Questo 
script può eseguire automaticamente dei nuovi controlli di sicurezza 
per far sì che l'utente sia certo che il software che sta scaricando 
sia lo stesso che Debian distribuisce. Ciò impedisce agli 
sviluppatori Debian di violare il sistema di qualcuno senza la
garanzia di autenticità derivante dall'inclusione nell'archivio
principale, ai mirror di fornire qualcosa di molto simile a Debian ma
non esattamente uguale ad essa, o copie non aggiornate di unstable
con problemi di sicurezza noti.

<p>Questo semplice codice, rinominato come <prgn>apt-check-sigs</prgn>, 
dovrebbe essere usato nel modo seguente:
<example>
# apt-get update
# apt-check-sigs
(...results...)
# apt-get dist-upgrade
</example>

<p>Per prima cosa avete bisogno di:

<list>

<item>Ottenere le chiavi che l'archivio software utilizza per 
firmare i file <file>Release</file>, <url 
id="http://ftp-master.debian.org/ziyi_key_2006.asc"> e aggiungerli 
a <file>~/.gnupg/trustedkeys.gpg</file> (che è quello che 
<prgn>gpgv</prgn> usa in modo predefinito).
<example>
  gpg --no-default-keyring --keyring trustedkeys.gpg --import ziyi_key_2006.asc
</example>

<item>Rimuovere tutte le righe di <file>/etc/apt/sources.list</file> 
che non usano la normale struttura "dists" o modificare lo script in 
modo che funzioni con esse.
<item>Essere preparati ad ignorare il fatto che gli aggiornamenti di 
sicurezza di Debian non hanno file <file>Release</file> firmati e che 
i file <file>Sources</file> non hanno (ancora) un checksum 
appropriato nel file <file>Release</file>.
<item>Essere pronti a verificare che i sorgenti siano firmati da chiavi
appropriate.

</list>

<p>Questo è il codice di esempio per <prgn>apt-check-sigs</prgn>, 
la versione più recente è reperibile presso 
<url id="http://people.debian.org/~ajt/apt-check-sigs">.
Questo codice è attualmente in beta, per maggiori informazioni leggete 
<url id="http://lists.debian.org/debian-devel/2002/debian-devel-200207/msg00421.html">.

<example>
#!/bin/bash

# Copyright (c) 2001 Anthony Towns &lt;ajt@debian.org&gt;
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.

rm -rf /tmp/apt-release-check
mkdir /tmp/apt-release-check || exit 1
cd /tmp/apt-release-check

>OK
>MISSING
>NOCHECK
>BAD

arch=`dpkg --print-installation-architecture`

am_root () {
        [ `id -u` -eq 0 ]
}

get_md5sumsize () {
        cat "$1" | awk '/^MD5Sum:/,/^SHA1:/' | 
          MYARG="$2" perl -ne '@f = split /\s+/; if ($f[3] eq $ENV{"MYARG"}) {
print "$f[1] $f[2]\n"; exit(0); }'
}

checkit () {
        local FILE="$1"
        local LOOKUP="$2"

        Y="`get_md5sumsize Release "$LOOKUP"`"
        Y="`echo "$Y" | sed 's/^ *//;s/  */ /g'`"

        if [ ! -e "/var/lib/apt/lists/$FILE" ]; then
                if [ "$Y" = "" ]; then
                        # No file, but not needed anyway
                        echo "OK"
                        return
                fi
                echo "$FILE" >>MISSING
                echo "MISSING $Y"
                return
        fi
        if [ "$Y" = "" ]; then
                echo "$FILE" >>NOCHECK
                echo "NOCHECK"
                return
        fi
        X="`md5sum &lt; /var/lib/apt/lists/$FILE | cut -d\  -f1` `wc -c &lt; /var/lib
/apt/lists/$FILE`"
        X="`echo "$X" | sed 's/^ *//;s/  */ /g'`"
        if [ "$X" != "$Y" ]; then
                echo "$FILE" >>BAD
                echo "BAD"
                return
        fi
        echo "$FILE" >>OK
        echo "OK"
}

echo
echo "Checking sources in /etc/apt/sources.list:"
echo "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"
echo
(echo "You should take care to ensure that the distributions you're downloading
"
echo "are the ones you think you are downloading, and that they are as up to"
echo "date as you would expect (testing and unstable should be no more than"
echo "two or three days out of date, stable-updates no more than a few weeks"
echo "or a month)."
) | fmt
echo

cat /etc/apt/sources.list | 
  sed 's/^ *//' | grep '^[^#]' |
  while read ty url dist comps; do
        if [ "${url%%:*}" = "http" -o "${url%%:*}" = "ftp" ]; then
                baseurl="${url#*://}"
        else
                continue
        fi

        echo "Source: ${ty} ${url} ${dist} ${comps}"

        rm -f Release Release.gpg
        lynx -reload -dump "${url}/dists/${dist}/Release" >/dev/null 2>&1
        wget -q -O Release "${url}/dists/${dist}/Release"

        if ! grep -q '^' Release; then
                echo "  * NO TOP-LEVEL Release FILE"
                >Release
        else
                origline=`sed -n 's/^Origin: *//p' Release | head -1`
                lablline=`sed -n 's/^Label: *//p' Release | head -1`
                suitline=`sed -n 's/^Suite: *//p' Release | head -1`
                codeline=`sed -n 's/^Codename: *//p' Release | head -1`
                dateline=`grep "^Date:" Release | head -1`
                dscrline=`grep "^Description:" Release | head -1`
                echo "  o Origin: $origline/$lablline"
                echo "  o Suite: $suitline/$codeline"
                echo "  o $dateline"
                echo "  o $dscrline"

                if [ "${dist%%/*}" != "$suitline" -a "${dist%%/*}" != "$codeline" ]; then
                        echo "  * WARNING: asked for $dist, got $suitline/$codeline"
                fi

                lynx -reload -dump "${url}/dists/${dist}/Release.gpg" >/dev/null 2>&1
                wget -q -O Release.gpg "${url}/dists/${dist}/Release.gpg"

                gpgv --status-fd 3 Release.gpg Release 3>&1 >/dev/null 2>&1 | sed -n "s/^\[GNUPG:\] //p" | (okay=0; err=""; while read gpgcode rest; do
                        if [ "$gpgcode" = "GOODSIG" ]; then
                            if [ "$err" != "" ]; then
                                echo "  * Signed by ${err# } key: ${rest#* }"
                            else
                                echo "  o Signed by: ${rest#* }"
                                okay=1
                            fi
                            err=""
                        elif [ "$gpgcode" = "BADSIG" ]; then
                            echo "  * BAD SIGNATURE BY: ${rest#* }"
                            err=""
                        elif [ "$gpgcode" = "ERRSIG" ]; then
                            echo "  * COULDN'T CHECK SIGNATURE BY KEYID: ${rest %% *}"
                            err=""
                        elif [ "$gpgcode" = "SIGREVOKED" ]; then
                            err="$err REVOKED"
                        elif [ "$gpgcode" = "SIGEXPIRED" ]; then
                            err="$err EXPIRED"
                        fi
                    done
                    if [ "$okay" != 1 ]; then
                        echo "  * NO VALID SIGNATURE"
                        >Release
                    fi)
        fi
        okaycomps=""
        for comp in $comps; do
                if [ "$ty" = "deb" ]; then
                        X=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/binary-${arch}/Release" | sed 's,//*,_,g'`" "${comp}/binary-${arch}/Release")
                        Y=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/binary-${arch}/Packages" | sed 's,//*,_,g'`" "${comp}/binary-${arch}/Packages")
                        if [ "$X $Y" = "OK OK" ]; then
                                okaycomps="$okaycomps $comp"
                        else
                                echo "  * PROBLEMS WITH $comp ($X, $Y)"
                        fi
                elif [ "$ty" = "deb-src" ]; then
                        X=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/source/Release" | sed 's,//*,_,g'`" "${comp}/source/Release")
                        Y=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/source/Sources" | sed 's,//*,_,g'`" "${comp}/source/Sources")
                        if [ "$X $Y" = "OK OK" ]; then
                                okaycomps="$okaycomps $comp"
                        else
                                echo "  * PROBLEMS WITH component $comp ($X, $Y)"
                        fi
                fi
        done
        [ "$okaycomps" = "" ] || echo "  o Okay:$okaycomps"
        echo
  done

echo "Results"
echo "~~~~~~~"
echo

allokay=true

cd /tmp/apt-release-check
diff &lt;(cat BAD MISSING NOCHECK OK | sort) &lt;(cd /var/lib/apt/lists && find . -type f -maxdepth 1 | sed 's,^\./,,g' | grep '_' | sort) | sed -n 's/^> //p' >UNVALIDATED

cd /tmp/apt-release-check
if grep -q ^ UNVALIDATED; then
    allokay=false
    (echo "The following files in /var/lib/apt/lists have not been validated."
    echo "This could turn out to be a harmless indication that this script"
    echo "is buggy or out of date, or it could let trojaned packages get onto"
    echo "your system."
    ) | fmt
    echo
    sed 's/^/    /' &lt; UNVALIDATED
    echo
fi

if grep -q ^ BAD; then
    allokay=false
    (echo "The contents of the following files in /var/lib/apt/lists does not"
    echo "match what was expected. This may mean these sources are out of date,"
    echo "that the archive is having problems, or that someone is actively"
    echo "using your mirror to distribute trojans."
    if am_root; then 
        echo "The files have been renamed to have the extension .FAILED and"
        echo "will be ignored by apt."
        cat BAD | while read a; do
            mv /var/lib/apt/lists/$a /var/lib/apt/lists/${a}.FAILED
        done
    fi) | fmt
    echo
    sed 's/^/    /' &lt; BAD
    echo
fi

if grep -q ^ MISSING; then
    allokay=false
    (echo "The following files from /var/lib/apt/lists were missing. This"
    echo "may cause you to miss out on updates to some vulnerable packages."
    ) | fmt
    echo
    sed 's/^/    /' &lt; MISSING
    echo
fi

if grep -q ^ NOCHECK; then
    allokay=false
    (echo "The contents of the following files in /var/lib/apt/lists could not"
    echo "be validated due to the lack of a signed Release file, or the lack"
    echo "of an appropriate entry in a signed Release file. This probably"
    echo "means that the maintainers of these sources are slack, but may mean"
    echo "these sources are being actively used to distribute trojans."
    if am_root; then 
        echo "The files have been renamed to have the extension .FAILED and"
        echo "will be ignored by apt."
        cat NOCHECK | while read a; do
            mv /var/lib/apt/lists/$a /var/lib/apt/lists/${a}.FAILED
        done
    fi) | fmt
    echo
    sed 's/^/    /' &lt; NOCHECK
    echo
fi

if $allokay; then
    echo 'Everything seems okay!'
    echo
fi

rm -rf /tmp/apt-release-check
</example>

<p>Potrebbe essere necessario applicare questa patch per <em>sid</em>
perché <prgn>md5sum</prgn> aggiunge un '-' dopo la somma quando 
l'input è stdin:

<example>
@@ -37,7 +37,7 @@
        local LOOKUP="$2"

        Y="`get_md5sumsize Release "$LOOKUP"`"
-       Y="`echo "$Y" | sed 's/^ *//;s/  */ /g'`"
+       Y="`echo "$Y" | sed 's/-//;s/^ *//;s/  */ /g'`"

        if [ ! -e "/var/lib/apt/lists/$FILE" ]; then
                if [ "$Y" = "" ]; then
@@ -55,7 +55,7 @@
                return
        fi
        X="`md5sum &lt; /var/lib/apt/lists/$FILE` `wc -c &lt; /var/lib/apt/lists/$FILE`"
-       X="`echo "$X" | sed 's/^ *//;s/  */ /g'`"
+       X="`echo "$X" | sed 's/-//;s/^ *//;s/  */ /g'`"
        if [ "$X" != "$Y" ]; then
                echo "$FILE" >>BAD
                echo "BAD"
</example>

<sect1 id="check-non-debian-releases">Controllo della versione su 
                                      fonti esterne a Debian


<p>Notate che, usando l'ultima versione di apt (la versione
<em>sicura di apt</em>), l'utente non dovrebbe fare 
alcunché, a meno che non utilizzi fonti esterne a Debian, nel qual 
caso apt-get richiederà un'ulteriore conferma. 
Questo si può evitare fornendo i file <file>Release</file> e 
<file>Release.gpg</file> tra le fonti esterne non-Debian. Il file 
<file>Release</file> può essere generato con 
<prgn>apt-ftparchive</prgn> (disponibile in 
<package>apt-utils</package> 0.5.0 e successivi), mentre 
<file>Release.gpg</file> è semplicemente una firma separata. Per 
generarli entrambi seguite questa semplice procedura:

<example>
$ rm -f dists/unstable/Release
$ apt-ftparchive release dists/unstable > dists/unstable/Release
$ gpg --sign -ba -o dists/unstable/Release.gpg dists/unstable/Release
</example>

<sect1 id="check-pkg-sign">Un modello alternativo di firma per ciascun pacchetto

<p>L'ulteriore modello per firmare ogni pacchetto, ne permette il
controllo quando questi non hanno più riferimenti in un file
<file>Packages</file> già esistente. Così facendo, anche se i 
pacchetti sono provenienti da terze parti di Debian, potranno 
comunque essere usati in Debian, ma non con lo schema predefinito.

<p>Questo modo di firmare i pacchetti può essere implementato usando
<package>debsig-verify</package> e <package>debsigs</package>.
Questi due pacchetti possono firmare e verificare firme all'interno 
dello stesso pacchetto .deb. Debian ha già adesso la capacità di fare 
tutto ciò, ma non c'è un piano per implementare questa funzionalità 
nella policy o in altri strumenti, dal momento che viene preferita la 
firma degli archivi. Questi strumenti sono a disposizione di utenti 
ed amministratori che invece preferiscono usare quest'altro metodo.

<p>Le ultime versioni di <prgn>dpkg</prgn> (dalla 1.9.21) incorporano 
una <url 
id="http://lists.debian.org/debian-dpkg/2001/debian-dpkg-200103/msg00024.html" 
name="patch"> che fornisce questa funzionalità non appena 
<package>debsig-verify</package> viene installato.


<p>NOTE: Attualmente <file>/etc/dpkg/dpkg.cfg</file> nasce con 
"no-debsig" come valore predefinito.

<p>NOTE2: Le firme degli sviluppatori attualmente vengono 
eliminate quando depositano il pacchetto nell'archivio poiché 
lo stile attualmente in voga consiste nel controllare la release 
come descritto precedentemente.










