FIXME: probably the Internet Explorer vulnerability handling. certificate chains has an impact on security updates on Microsoft Windows.
7.5.1. The current scheme for package signature checks
L'attuale (non implementato) schema di controllo della firma dei pacchetti usando
apt
è il seguente:
Il file Release
include la somma MD5 di Packages.gz (che contiene le somme MD5 dei pacchetti) e verrà firmato. La firma è una delle fonti certe.
Questo file Release
firmato viene scaricato con 'apt-get update' e conservato insieme a Packages.gz
.
Quando un pacchetto sta per essere installato, viene prima scaricato, successivamente viene generata la somma MD5.
Il file Release
firmato viene controllato (la firma è ok) e viene estratto da questo la somma MD5 per il file Packages.gz
, il checksum di Packages.gz
viene generato e (se ok) la somma MD5 del pacchetto scaricato viene calcolata direttamente da sé stesso.
Se la somma MD5 del pacchetto scaricato è la stessa di quella nel file Packages.gz
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 Packages.gz
e l'amministratore ha configurato il sistema per installare solo pacchetti firmati non sarà nemmeno installabile.
Seguendo la catena delle somme MD5 apt
è 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).
The apt 0.6 release, available since Debian 4.0 etch and later releases, includes apt-secure (also known as secure apt) which is a tool that will allow a system administrator to test the integrity of the packages downloaded through the above scheme. This release includes the tool apt-key
for adding new keys to apt's keyring, which by default includes only the current Debian archive signing key.
This feature is still under development, if you believe you find bugs in it, please, make first sure you are using the latest version (as this package might change quite a bit before it is finally released) and, if running the latest version, submit a bug against the apt package.
7.5.3. Controllo di rilascio per ogni distribuzione
Questa sezione descrive come il meccanismo di controllo del rilascio della distribuzione funzioni, fu scritto da Joey Hess ed è disponibile anche presso il
http://wiki.debian.org/SecureApt.
7.5.3.1. Concetti di base
Qui diamo alcuni concetti di base necessari per capire il resto di questa sezione.
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.
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. È 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.
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.
gpg
è lo strumento usato nella versione sicura di apt per firmare i file e verificarne le firme.
apt-key
è un programma che viene usato per gestire un portachiavi di chiavi gpg per apt sicuro. Il portachiavi viene mantenuto nel file /etc/apt/trusted.gpg
(da non confondersi con file /etc/apt/trustdb.gpg
sempre legato ad apt, ma non troppo interessante). apt-key
può essere usato per mostrare le chiavi del portachiavi, per aggiungerne e per rimuoverne altre.
7.5.3.2. Checksum di Release
Un archivio Debian contiene un file
Release
, che viene aggiornato ogni volta che un pacchetto dell'archivio cambia. Tra l'altro, il file
Release
contiene le somme MD5 di altri file presenti nell'archivio. Un estratto di un file
Release
di esempio:
MD5Sum:
6b05b392f792ba5a436d590c129de21f 3453 Packages
1356479a23edda7a69f24eb8d6f4a14b 1131 Packages.gz
2a5167881adc9ad1a8864f281b1eb959 1715 Sources
88de3533bf6e054d1799f8e49b6aed8b 658 Sources.gz
I file Release
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.
Adesso, se guardiamo in un file
Packages
, troveremo diversi checksum MD5, uno per ogni pacchetto elencato. Ad esempio:
Package: uqm
Priority: optional
...
Filename: unstable/uqm_0.4.0-1_i386.deb
Size: 580558
MD5sum: 864ec6157c1eea88acfef44d0f34d219
Questi due checksum possono essere usati per verificare che si sia scaricata una versione corretta del file Packages
, con un md5sum che corrisponde con quello del file Release
. Inoltre, quando scaricate un singolo pacchetto, potete verificare il suo md5sum con quello contenuto nel file Packages
. Se apt fallisce entrambi questi passi, abortisce.
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 Release
. Questa versione sicura di apt ruota tutto attorno alla verifica del file Release
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.
7.5.3.3. Verifica del file Release
Per verificare il file
Release
, viene aggiunta al file una firma gpg. Questa viene messa in un file chiamato
Release.gpg
che viene fornito assieme al file
Release
. Assomiglia a qualcosa del genere
, anche se di solito solo gpg guarda il suo contenuto:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQBCqKO1nukh8wJbxY8RAsfHAJ9hu8oGNRAl2MSmP5+z2RZb6FJ8kACfWvEx
UBGPVc7jbHHsg78EhMBlV/U=
=x6og
-----END PGP SIGNATURE-----
7.5.3.4. Verifica del file Release.gpg
da parte di apt
La versione sicura di Apt scarica sempre i file
Release.gpg
quando scarica i file
Release
e se non riesce a farlo, o se la firma non è valida, si lamenterà ed annoterà che il file
Packages
a cui il file
Release
punta, con tutti i pacchetti elencati al suo interno, provengono da una sorgente non fidata. Ecco a cosa somiglia un'operazione come
apt-get update
:
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
Notate che la seconda metà del numero "long" è l'identificativo della chiave che apt non conosce, e in questo caso è 2D230C5F.
Se ignorerete l'avvertimento e tenterete di installare un pacchetto più avanti, apt avvertirà nuovamente:
WARNING: The following packages cannot be authenticated!
libglib-perl libgtk2-perl
Install these packages without verification [y/N]?
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
.
Notate che potete disabilitare questi controlli eseguendo apt con l'opzione --allow-unauthenticated.
Vale anche la pena notare che le nuove versioni dell'installatore Debian usano lo stesso meccanismo del file Release
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 Release
nei CD; apt può essere comunque configurato per fidarsi sempre dei pacchetti dai CD così che questo non sia un grosso problema.
7.5.3.5. Come dire ad apt di cosa fidarsi
Quindi la sicurezza dell'intero sistema dipende dalla presenza di un file Release.gpg
, che firma un file Release
e da apt
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 (/etc/apt/trusted.gpg
) e con la gestione delle chiavi fa il suo ingresso la versione sicura di apt.
I sistemi Debian vengono configurati, in modo predefinito, con la chiave dell'archivio Debian nel portachiavi.
# apt-key list
/etc/apt/trusted.gpg
--------------------
pub 1024D/4F368D5D 2005-01-31 [expires: 2006-01-31]
uid Debian Archive Automatic Signing Key (2005) <[email protected]>
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.
That will make apt
trust the official Debian archive, but if you add some other apt repository to /etc/apt/sources.list
, you'll also have to give apt
its key if you want apt to trust it. Once you have the key and have verified it, it's a simple matter of running apt-key add
file to add it. Getting the key and verifying it are the trickier parts.
7.5.3.6. Come ottenere la chiave di un repository
Il pacchetto debian-archive-keyring viene usato per distribuire le chiavi tramite apt
. Aggiornate questo pacchetto per aggiungere (o rimuovere) chiavi gpg relative all'archivio principale di Debian.
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.
Lo stesso programma
gpg
ha una procedura standard per distribuire le chiavi, scaricando le chiavi da un server apposito ed aggiungendole al suo portachiavi. Per esempio:
$ 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) <ftpm
[email protected]>" imported
gpg: Total number processed: 1
gpg: imported: 1
Potete poi esportare tale chiave dal vostro portachiavi e fornirla al programma
apt-key
:
$ gpg -a --export 2D230C5F | sudo apt-key add -
gpg: no ultimately trusted keys found
OK
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
http://it.wikipedia.org/wiki/Web_of_trust usata da OpenPGP ed in questo caso potete ignorarlo. In una configurazione tipica, viene data fiducia indiscussa alla chiave dell'utente.
7.5.3.7. Come aggiungere una chiave in maniera sicura
By adding a key to apt's keyring, you're telling apt to trust everything signed by the key, and this lets you know for sure that apt won't install anything not signed by the person who possesses the private key. But if you're sufficiently paranoid, you can see that this just pushes things up a level, now instead of having to worry if a package, or a
Release
file is valid, you can worry about whether you've actually gotten the right key. Is the key file from
https://ftp-master.debian.org/keys.html mentioned above really Debian's archive signing key, or has it been modified (or this document lies).
It's good to be paranoid in security, but verifying things from here is harder.
gpg
has the concept of a chain of trust, which can start at someone you're sure of, who signs someone's key, who signs some other key, etc., until you get to the archive key. If you're sufficiently paranoid you'll want to check that your archive key is signed by a key that you can trust, with a trust chain that goes back to someone you know personally. If you want to do this, visit a Debian conference or perhaps a local LUG for a key signing
.
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.
7.5.3.8. Verifica dell'integrità della chiave
You can verify the fingerprint as well as the signatures on the key. Retrieving the fingerprint can be done for multiple sources, you can talk to Debian Developers on IRC, read the mailing list where the key change will be announced or any other additional means to verify the fingerprint. For example you can do this:
$ GET http://ftp-master.debian.org/ziyi_key_2006.asc | gpg --import
gpg: key 2D230C5F: public key "Debian Archive Automatic Signing Key (2006)
<ftpmaster&debian.org>" 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) <[email protected]>
sig!3 2D230C5F 2006-01-03 Debian Archive Automatic Signing Key
(2006) <[email protected]>
sig! 2A4E3EAA 2006-01-03 Anthony Towns <[email protected]>
sig! 4F368D5D 2006-01-03 Debian Archive Automatic Signing Key
(2005) <[email protected]>
sig! 29982E5A 2006-01-04 Steve Langasek <[email protected]>
sig! FD6645AB 2006-01-04 Ryan Murray <[email protected]>
sig! AB2A91F5 2006-01-04 James Troup <[email protected]>
and then as in
Sezione 7.5, «Firma dei pacchetti in Debian» check the trust path from your key (or a key you trust) to at least one of the keys used to sign the archive key. If you are sufficiently paranoid you will tell apt to trust the key only if you find an acceptable path:
$ gpg --export -a 2D230C5F | sudo apt-key add -
Ok
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.
7.5.3.9. Rinnovo annuale delle chiavi degli archivi Debian
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.
Nel gennaio 2006 il file Release
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.
Nel gennaio 2006, fu creata una nuova chiave per il 2006 e si cominciò a firmare con essa il file Release
, ma per cercare di non rompere la compatibilità con i sistemi che avevano ancora la vecchia chiave del 2005, il file Release
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.
7.5.3.10. Problemi noti sul controllo della versione
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:
W: GPG error: http://archive.progeny.com sid Release: Unknown error executing gpg
In ogni caso
apt-key
renderà chiaro il problema:
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) <[email protected]>
Se invece segna una data troppo distante nel futuro, apt considererà le chiavi come scadute.
Un altro problema in cui vi potete imbattere usando testing o unstable è che, se non avete eseguito recentemente apt-get update
prima di apt-get install
su di un pacchetto che volete installare, apt potrebbe lamentarsi di non potersi autenticare (perché lo fa?). apt-get update
correggerà il problema.
7.5.3.11. Controllare manualmente i rilasci della distribuzione
Nel caso in cui vogliate aggiungere adesso i controlli di sicurezza aggiuntivi e non vogliate o possiate eseguire l'ultima versione di apt
, 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.
Questo semplice codice, rinominato come
apt-check-sigs
, dovrebbe essere usato nel modo seguente:
# apt-get update
# apt-check-sigs
(...results...)
# apt-get dist-upgrade
Per prima cosa avete bisogno di:
get the keys the archive software uses to sign
Release
files from
https://ftp-master.debian.org/keys.html and add them to
~/.gnupg/trustedkeys.gpg
(which is what
gpgv
uses by default).
gpg --no-default-keyring --keyring trustedkeys.gpg --import ziyi_key_2006.asc
Rimuovere tutte le righe di /etc/apt/sources.list
che non usano la normale struttura "dists" o modificare lo script in modo che funzioni con esse.
Essere preparati ad ignorare il fatto che gli aggiornamenti di sicurezza di Debian non hanno file Release
firmati e che i file Sources
non hanno (ancora) un checksum appropriato nel file Release
.
Essere pronti a verificare che i sorgenti siano firmati da chiavi appropriate.
This is the example code for
apt-check-sigs
, the latest version can be retrieved from
http://people.debian.org/~ajt/apt-check-sigs. This code is currently in beta, for more information read
http://lists.debian.org/debian-devel/2002/07/msg00421.html.
#!/bin/bash
# Copyright (c) 2001 Anthony Towns <[email protected]>
#
# 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 < /var/lib/apt/lists/$FILE | cut -d\ -f1` `wc -c < /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 <(cat BAD MISSING NOCHECK OK | sort) <(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/^/ /' < 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/^/ /' < 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/^/ /' > 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/^/ /' > NOCHECK
echo
fi
if $allokay; then
echo 'Everything seems okay!'
echo
fi
rm -rf /tmp/apt-release-check
Potrebbe essere necessario applicare questa patch per
sid perché
md5sum
aggiunge un '-' dopo la somma quando l'input è stdin:
@@ -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 < /var/lib/apt/lists/$FILE` `wc -c < /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"
7.5.5. Un modello alternativo di firma per ciascun pacchetto
L'ulteriore modello per firmare ogni pacchetto, ne permette il controllo quando questi non hanno più riferimenti in un file Packages
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.
This package signing scheme can be implemented using debsig-verify and debsigs. These two packages can sign and verify embedded signatures in the .deb itself. Debian already has the capability to do this now, but there is no feature plan to implement the policy or other tools since the archive signing scheme is prefered. These tools are available for users and archive administrators that would rather use this scheme instead.
NOTE: Attualmente /etc/dpkg/dpkg.cfg
nasce con "no-debsig" come valore predefinito.
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.