]> git.saurik.com Git - apt-legacy.git/blob - doc/fr/apt-secure.8
Apparently apt-ftparchive uses Berkeley DB.
[apt-legacy.git] / doc / fr / apt-secure.8
1 .\" Title: apt\-secure
2 .\" Author: Jason Gunthorpe
3 .\" Generator: DocBook XSL Stylesheets v1.71.0 <http://docbook.sf.net/>
4 .\" Date: 14 décembre 2003
5 .\" Manual:
6 .\" Source: Linux
7 .\"
8 .TH "APT\-SECURE" "8" "14 décembre 2003" "Linux" ""
9 .\" disable hyphenation
10 .nh
11 .\" disable justification (adjust text to left margin only)
12 .ad l
13 .SH "NOM"
14 apt\-secure \- Certification d'archive avec APT
15 .SH "DESCRIPTION"
16 .PP
17 Depuis sa version 0.6,
18 \fBapt\fR
19 sait vérifier la signature du fichier Release de chaque archive. On s'assure ainsi que les paquets de cette archive ne peuvent pas être modifiés par quelqu'un qui ne possède pas la clé de la signature du fichier Release.
20 .PP
21 Quand un paquet provient d'une archive sans signature ou d'une archive avec une signature dont apt ne possède pas la clé, ce paquet n'est pas considéré comme fiable et son installation provoquera un avertissement. Pour l'instant,
22 \fBapt\-get\fR
23 ne signale que les archives sans signature\ ; les prochaines versions pourraient rendre obligatoire la vérification des sources avant tout téléchargement de paquet.
24 .PP
25 Les paquets
26 \fBapt\-get\fR(8),
27 \fBaptitude\fR(8)
28 et
29 \fBsynaptic\fR(8)
30 possèdent cette nouvelle fonction de certification.
31 .SH "ARCHIVES FIABLES"
32 .PP
33 D'une archive apt jusqu'à l'utilisateur, la confiance se construit en plusieurs étapes.
34 \fBApt\-secure\fR
35 est la dernière étape. Faire confiance à une archive ne signifie pas que les paquets qu'elle contient sont exempts de code malveillant, mais signifie que vous faites confiance au responsable de l'archive. C'est ensuite au responsable de l'archive de faire en sorte que l'archive soit fiable.
36 .PP
37 \fBApt\-secure\fR
38 n'examine pas la signature d'un paquet. Certains programmes peuvent le faire comme
39 \fBdebsig\-verify\fR
40 ou
41 \fBdebsign\fR, qu'on peut trouver dans les paquets debsig\-verify et devscripts.
42 .PP
43 La fiabilisation dans Debian commence quand un responsable de paquet envoie un nouveau paquet ou une nouvelle version d'un paquet dans l'archive. Cet envoi, pour être effectif, doit être signé avec la clé d'un responsable qui se trouve dans le trousseau des responsables Debian (disponible dans le paquet debian\-keyring). Les clés des responsables de paquet sont signées par d'autres responsables, suivant des procédures préétablies pour s'assurer de l'identité des propriétaires de la clé.
44 .PP
45 Une fois le paquet vérifié et archivé, la signature du responsable est enlevée, une somme MD5 du paquet est calculée et mise dans le fichier Packages. Une somme MD5 de tous les paquets est ensuite calculée et mise dans le fichier Release. Ce fichier est signé par la clé de l'archive. Cette clé qui est créée chaque année et distribuée par le serveur FTP se trouve aussi dans le trousseau Debian.
46 .PP
47 Un utilisateur peut consulter la signature du fichier Release, extraire la somme MD5 d'un paquet et la comparer avec la somme du paquet qu'il a téléchargé. Avant la version 0.6, seule la somme du paquet téléchargé était vérifiée. Maintenant on peut vérifier aussi la signature du fichier Release.
48 .PP
49 Cette façon de faire est différente d'une vérification de la signature d'un paquet. Elle vise à empêcher deux types d'attaque possibles\ :
50 .TP 3n
51 \(bu
52 L'attaque de type
53 \(Fo\ homme au milieu\ \(Fc. Sans vérification de signature, quelqu'un de malveillant peut s'introduire au milieu du processus de téléchargement et insérer du code soit en contrôlant un élément du réseau, routeur, commutateur, etc. soit en détournant le trafic vers un serveur fourbe (par usurpation d'adresses).
54 .TP 3n
55 \(bu
56 L'attaque par compromission d'un miroir sur le réseau. Sans vérification de signature, quelqu'un de malveillant peut compromettre un miroir et modifier les fichiers. Ainsi tous ceux qui téléchargent les paquets de ce miroir propagent du code malveillant.
57 .PP
58 Cependant cette méthode ne garantit pas contre une compromission du serveur Debian lui\-même (qui signe les paquets) ni contre la compromission de la clé qui sert à signer les fichiers Release. Mais elle peut compléter la signature des paquets.
59 .SH "CONFIGURATION"
60 .PP
61 Le programme qui gère la liste des clés utilisées par apt s'appelle
62 \fBapt\-key\fR. Il peut ajouter ou supprimer des clés. Cette version installe automatiquement les clés qui servent à signer l'archive Debian et les différents répertoires de paquets.
63 .PP
64 Pour ajouter une clé, vous devez d'abord la télécharger. Il vaut mieux utiliser un canal fiable pour ce téléchargement. Ensuite vous l'ajoutez avec la commande
65 \fBapt\-key\fR
66 et vous lancez la commande
67 \fBapt\-get update\fR
68 pour télécharger et vérifier le fichier
69 \fIRelease.gpg\fR
70 de l'archive que vous avez configurée.
71 .SH "CONFIGURATION D'UNE ARCHIVE"
72 .PP
73 Si vous voulez signer les archives dont vous avez la responsabilité, vous devez\ :
74 .TP 3n
75 \(bu
76 créer un fichier Release à la racine de l'archive, s'il n'existe pas déjà. Vous pouvez le créer avec la commande
77 \fBapt\-ftparchive release\fR
78 (fournie dans le paquet apt\-utils)\ ;
79 .TP 3n
80 \(bu
81 le signer, avec la commande
82 \fBgpg \-abs \-o Release.gpg Release\fR\ ;
83 .TP 3n
84 \(bu
85 publier l'empreinte de la clé. Ainsi les utilisateurs de votre archive connaîtront la clé qu'ils doivent importer pour authentifier les fichiers de l'archive.
86 .PP
87 Chaque fois que le contenu de l'archive change, le responsable doit refaire les deux premières étapes.
88 .SH "VOIR AUSSI"
89 .PP
90
91 \fBapt.conf\fR(5),
92 \fBapt\-get\fR(8),\fBsources.list\fR(5),
93 \fBapt\-key\fR(8),
94 \fBapt\-archive\fR(1),
95 \fBdebsign\fR(1),
96 \fBdebsig\-verify\fR(1),
97 \fBgpg\fR(1)
98 .PP
99 Pour des informations plus substantielles, vous pouvez consulter
100 [1]\&\fI l'infrastructure debian pour la sécurité\fR
101 un chapitre du manuel Debian sur la sécurité (disponible dans le paquet harden\-doc) et le
102 [2]\&\fIStrong Distribution HOWTO\fR
103 par V. Alex Brennen.
104 .SH "BOGUES"
105 .PP
106 Voyez la
107 [3]\&\fI page concernant les bogues d'APT\fR. Si vous voulez signaler un bogue, consultez le texte
108 \fI/usr/share/doc/debian/bug\-reporting.txt\fR
109 ou utilisez la commande
110 \fBreportbug\fR(1).
111 .SH "AUTEUR"
112 .PP
113 APT a été écrit par l'équipe APT
114 <apt@packages.debian.org>.
115 .SH "AUTEURS"
116 .PP
117 Cette page a été écrite à partir des travaux de Javier Fernández\-Sanguino Peña, Isaac Jones, Colin Walters, Florian Weimer et Michael Vogt.
118 .SH "TRADUCTION"
119 .PP
120 Philippe Batailler.
121 <debian\-l10n\-french@lists.debian.org>. 2005.
122 .SH "AUTEUR"
123 .PP
124 \fBJason Gunthorpe\fR
125 .sp -1n
126 .IP "" 3n
127 Auteur.
128 .SH "COPYRIGHT"
129 Copyright \(co 1998\-2001 Jason Gunthorpe
130 .br
131 .SH "REFERENCES"
132 .TP 3
133 1.\ l'infrastructure debian pour la sécurité
134 \%http://www.debian.org/doc/manuals/securing\-debian\-howto/ch7.en.html
135 .TP 3
136 2.\ Strong Distribution HOWTO
137 \%http://www.cryptnet.net/fdp/crypto/strong_distro.html
138 .TP 3
139 3.\ page concernant les bogues d'APT
140 \%http://bugs.debian.org/src:apt