tag:linuxfr.org,2005:/tags/cl%C3%A9/publicLinuxFr.org : les contenus étiquetés avec « clé »2022-03-06T02:11:45+01:00/favicon.pngtag:linuxfr.org,2005:Post/427112022-02-20T02:43:25+01:002022-02-20T02:43:25+01:00 double authentification<p>salut à tous ,</p>
<p>je souhaite mettre en place un système de double authentification sur mon pc via un mdp et une clé USB ou une clé type <br>
FIDO2 U2F.<br>
il me semble qu’il y a un module pam pour le faire ? une idée ?</p>
<div><a href="https://linuxfr.org/forums/linux-general/posts/double-authentification.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/126966/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/forums/linux-general/posts/double-authentification#comments">ouvrir dans le navigateur</a>
</p>
ultime-mega-ultra-rockhttps://linuxfr.org/nodes/126966/comments.atomtag:linuxfr.org,2005:Diary/395132020-12-19T13:35:01+01:002020-12-19T13:35:01+01:00Virus Mirai dans VentoyLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<p>Apparemment, le Trojan Mirai qui cible les systèmes Linux est présent dans plusieurs fichiers de Ventoy, une application qui permet de créer une clé USB pour démarrer plusieurs distributions Linux.<br>
<a href="https://github.com/ventoy/Ventoy/issues/660">https://github.com/ventoy/Ventoy/issues/660</a></p>
<p>Tous les fichiers infectés ont été ajoutés au dépôt par l'auteur du projet "longpanda" et non par des contributeurs. En attendant sa réponse, je conseille d'utiliser plutôt la clé USB MultiSystem : <a href="http://liveusb.info/dotclear/">http://liveusb.info/dotclear/</a></p>
<div><a href="https://linuxfr.org/users/devede/journaux/virus-mirai-dans-ventoy.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/122661/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/devede/journaux/virus-mirai-dans-ventoy#comments">ouvrir dans le navigateur</a>
</p>
DeVeDehttps://linuxfr.org/nodes/122661/comments.atomtag:linuxfr.org,2005:Post/415702020-11-08T15:37:04+01:002020-11-08T15:37:04+01:00Au secours ; LINUX malgré moi !!!<p><strong>Bonjour</strong>,<br>
je suis âgé de 12 ans et ma mère ayant acheter un ordinateur pour la famille et a installé Linux alors qu'elle ne connaît rien en informatique (elle a un PC portable sous Windows).<br>
Je trouve Linux très sympa mais j'aurais aimé garder Windows, car je ne trouve pas Linux pratique pour le travail.<br>
Voici mes problèmes:<br>
-<strong>je ne plus imprimer des document(imprimante HP Deskjet 2130)</strong> ;<br>
-<strong>les musique que je mets sur ma clé USB ne fonctionne pas sur mon poste radio</strong> ;<br>
-<strong>depuis que ma clé USB fut branchée sur Linux elle m'efface mes documents</strong> ;<br>
-<strong>on ne peut pas regarder de film en DVD</strong> .<br>
Ce serait avec grand plaisir que je recevrais toute aide via le forum 👍.<br>
<strong>Merci d'avance</strong> 👍 😳😳😳😳😳</p>
<div><a href="https://linuxfr.org/forums/linux-debutant/posts/au-secours-linux-malgre-moi.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/122153/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/forums/linux-debutant/posts/au-secours-linux-malgre-moi#comments">ouvrir dans le navigateur</a>
</p>
Millefacettehttps://linuxfr.org/nodes/122153/comments.atomtag:linuxfr.org,2005:Post/396442018-11-17T13:28:17+01:002018-11-19T18:49:43+01:00problème apt-get update "key"<p>voilà le probléme, aidez moi SVP</p>
<pre><code>Réception de:1 http://security.debian.org/debian-security stretch/updates InRelease [94,3 kB]
Err:1 http://security.debian.org/debian-security stretch/updates InRelease
Les signatures suivantes n'ont pas pu être vérifiées car la clé publique n'est pas disponible : NO_PUBKEY 9D6D8F6BC857C906 NO_PUBKEY 8B48AD6246925553
Réception de:3 https://deb.i2p2.de stretch InRelease [12,3 kB]
Err:3 https://deb.i2p2.de stretch InRelease
Les signatures suivantes n'ont pas pu être vérifiées car la clé publique n'est pas disponible : NO_PUBKEY 67ECE5605BCF1346
Réception de:2 http://kali.download/kali kali-rolling InRelease [30,5 kB]
Err:2 http://kali.download/kali kali-rolling InRelease
Les signatures suivantes n'ont pas pu être vérifiées car la clé publique n'est pas disponible : NO_PUBKEY ED444FF07D8D0BF6
Lecture des listes de paquets... Fait
W: Erreur de GPG : http://security.debian.org/debian-security stretch/updates InRelease : Les signatures suivantes n'ont pas pu être vérifiées car la clé publique n'est pas disponible : NO_PUBKEY 9D6D8F6BC857C906 NO_PUBKEY 8B48AD6246925553
E: Le dépôt http://security.debian.org/debian-security stretch/updates InRelease n'est pas signé.
N: Les mises à jour depuis un tel dépôt ne peuvent s'effectuer de manière sécurisée, et sont donc désactivées par défaut
N: Voir les pages de manuel d'apt-secure(8) pour la création des dépôts et les détails de configuration d'un utilisateur.
W: Erreur de GPG : https://deb.i2p2.de stretch InRelease : Les signatures suivantes n'ont pas pu être vérifiées car la clé publique n'est pas disponible : NO_PUBKEY 67ECE5605BCF1346
E: Le dépôt https://deb.i2p2.de stretch InRelease n'est pas signé.
N: Les mises à jour depuis un tel dépôt ne peuvent s'effectuer de manière sécurisée, et sont donc désactivées par défaut
N: Voir les pages de manuel d'apt-secure(8) pour la création des dépôts et les détails de configuration d'un utilisateur.
W: Erreur de GPG : http://kali.download/kali kali-rolling InRelease : Les signatures suivantes n'ont pas pu être vérifiées car la clé publique n'est pas disponible : NO_PUBKEY ED444FF07D8D0BF6
E: Le dépôt http://http.kali.org/kali kali-rolling InRelease n'est pas signé.
N: Les mises à jour depuis un tel dépôt ne peuvent s'effectuer de manière sécurisée, et sont donc désactivées par défaut
N: Voir les pages de manuel d'apt-secure(8) pour la création des dépôts et les détails de configuration d'un utilisateur.
</code></pre>
<div><a href="https://linuxfr.org/forums/linux-debian-ubuntu/posts/probleme-apt-get-update-key.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/115752/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/forums/linux-debian-ubuntu/posts/probleme-apt-get-update-key#comments">ouvrir dans le navigateur</a>
</p>
n00bscriptkiddiehttps://linuxfr.org/nodes/115752/comments.atomtag:linuxfr.org,2005:Bookmark/1132018-05-10T06:30:25+02:002018-05-10T06:30:25+02:00Vol de clefs (ajouté par des «attaquants» ?) dans le module Pipy "ssh-decorator" 0.28 à 0.31<a href="https://securityaffairs.co/wordpress/72298/malware/ssh-decorator-backdoor.html">https://securityaffairs.co/wordpress/72298/malware/ssh-decorator-backdoor.html</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/114427/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/ptifeth/liens/vol-de-clefs-ajoute-par-des-attaquants-dans-le-module-pipy-ssh-decorator-0-28-a-0-31#comments">ouvrir dans le navigateur</a>
</p>
fethhttps://linuxfr.org/nodes/114427/comments.atomtag:linuxfr.org,2005:Diary/373022017-05-11T17:35:38+02:002017-05-11T20:05:38+02:00De la distribution des clefs OpenPGPLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<h2 class="sommaire">Sommaire</h2>
<ul class="toc">
<li><a href="#introduction">Introduction</a></li>
<li>
<a href="#les-serveurs-de-clefs">Les serveurs de clefs</a><ul>
<li><a href="#un-peu-dhistoire">Un peu d’histoire</a></li>
<li><a href="#le-protocole-hkp">Le protocole HKP</a></li>
<li><a href="#les-serveurs-publics">Les serveurs publics</a></li>
<li><a href="#les-serveurs-ldap">Les serveurs LDAP</a></li>
<li>
<a href="#utilisation-avec-gnupg">Utilisation avec GnuPG</a><ul>
<li><a href="#dirmngr">Dirmngr</a></li>
<li><a href="#chercher-et-r%C3%A9cup%C3%A9rer-une-clef">Chercher et récupérer une clef</a></li>
<li><a href="#publier-une-clef">Publier une clef</a></li>
<li><a href="#rafra%C3%AEchir-les-clefs">Rafraîchir les clefs</a></li>
</ul>
</li>
</ul>
</li>
<li>
<a href="#publication-des-clefs-dans-le-dns">Publication des clefs dans le DNS</a><ul>
<li><a href="#la-m%C3%A9thode-moderne--dane">La méthode moderne : DANE</a></li>
<li>
<a href="#les-m%C3%A9thodes-historiques">Les méthodes historiques</a><ul>
<li><a href="#lenregistrement-cert">L’enregistrement CERT</a></li>
<li><a href="#les-enregistrements-pka">Les enregistrements PKA</a></li>
</ul>
</li>
</ul>
</li>
<li>
<a href="#le-protocole-openpgp-web-key-service">Le protocole OpenPGP Web Key Service</a><ul>
<li><a href="#le-web-key-directory">Le Web Key Directory</a></li>
<li><a href="#le-web-key-directory-update-protocol">Le Web Key Directory Update Protocol</a></li>
</ul>
</li>
<li><a href="#publication-dans-les-e-mails">Publication dans les e-mails</a></li>
<li><a href="#la-d%C3%A9couverte-automatique-des-clefs-avec-gnupg">La découverte automatique des clefs avec GnuPG</a></li>
<li><a href="#et-lauthentification-des-clefs">Et l’authentification des clefs ?</a></li>
</ul><h2 id="introduction">Introduction</h2>
<p>Un problème fréquemment rencontré avec <a href="https://tools.ietf.org/html/rfc4880">OpenPGP</a> est celui de la <em>distribution</em> des clefs publiques : comment Alice peut-elle transmettre sa clef publique à Bob, étape préalable indispensable à toute communication sécurisée ?</p>
<p>Depuis les premières versions de PGP, plusieurs méthodes ont été élaborées pour tenter de résoudre ce problème. Cet article les passe en revue.</p>
<h2 id="les-serveurs-de-clefs">Les serveurs de clefs</h2>
<p>La première méthode, la plus connue et celle historiquement associée au monde OpenPGP, consiste à enregistrer la clef auprès d’un <em>serveur de clefs</em>, qui la rendra disponible à quiconque la demande.</p>
<h3 id="un-peu-dhistoire">Un peu d’histoire</h3>
<p>Les premiers « serveurs de clefs » n’étaient en fait rien de plus que de simples serveurs FTP sur lesquels était disponible un trousseau de clefs publiques, par convention sous le chemin <code>/pub/pgp/keys/pubring.gpg</code> et dans un format directement utilisable par PGP. Un exemple d’un tel serveur était <code>ftp.pgp.net</code>, dont le contenu était « mirroré » sur plusieurs serveurs nationaux (<code>ftp.uk.pgp.net</code>, <code>ftp.de.pgp.net</code>, etc.).</p>
<p>Cette méthode est désormais complètement obsolète et la plupart des serveurs FTP de l’époque ne répondent même plus. À l’heure où j’écris ces lignes (décembre 2016), <code>ftp.pl.pgp.net</code> est l’un des rares encore actifs. Il héberge <a href="ftp://ftp.pl.pgp.net/pub/pgp/keys/pubring.pgp">un trousseau</a> contenant un peu plus de cinquante mille clefs, la plus récente datant de 2001.</p>
<p>Pour offrir davantage de fonctionnalités que ne le permettait la simple publication d’un trousseau à travers FTP, <a href="http://www.flame.org/%7Eexplorer/">Michael Graff</a> a écrit le premier véritable serveur de clefs à proprement parler, le PGP Keyserver Software,<sup id="fnref1"><a href="#fn1">1</a></sup> utilisant <a href="http://www.pgp.net/pgpnet/email-help-en.html">un protocole basé sur le courrier électronique</a>. Bien que lui aussi tombé aujourd’hui en désuétude, ce protocole est toujours partiellement supporté (en lecture seulement, sans possibilité de déposer une clef) par certains serveurs modernes. Ainsi, on pourra par exemple chercher les clefs associées à l’adresse <code>alice@example.org</code> en envoyant à <a href="mailto:pgp-public-keys@pool.sks-keyservers.net">pgp-public-keys@pool.sks-keyservers.net</a> un message contenant le sujet <code>INDEX alice@example.org</code>.</p>
<p>La deuxième génération de serveurs est apparue en 1996 avec le <a href="http://pks.sourceforge.net/">OpenPGP Public Key Server</a> (PKS), écrit par Marc Horowitz dans le cadre de <a href="http://www.mit.edu/afs/net.mit.edu/project/pks/thesis/paper/thesis.html">sa thèse au MIT</a>. Outre le protocole à base d’e-mail repris de la génération précédente, ce serveur a introduit le <em>HTTP Keyserver Protocol</em> (HKP). Basé sur le protocole HTTP comme son nom l’indique (quoiqu’il ait parfois été appelé <em>Horowitz Keyserver Protocol</em> en référence à son auteur), HKP fut décrit ultérieurement dans <a href="https://tools.ietf.org/id/draft-shaw-openpgp-hkp-00.txt">un brouillon IETF</a>. La spécification n’a jamais atteint le stade de RFC mais le protocole n’en est pas moins resté et est toujours aujourd’hui le protocole utilisé par les serveurs modernes.</p>
<p>Aujourd’hui, les serveurs modernes, justement, tournent pour la plupart sous <a href="https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Home">Synchronizing Key Server</a> (SKS), écrit initialement par Yaron Minsky et qui a largement supplanté PKS. Contrairement à ce que son nom pourrait laisser croire, SKS n’est pas le premier logiciel serveur permettant la synchronisation des serveurs de clefs (PKS le faisait déjà), mais SKS utilise pour cela un protocole dédié (sur le port 11370) couplé à un algorithme de réconciliation permettant de réduire le traffic nécessaire pour synchroniser deux serveurs (PKS utilisait une approche plus naïve et moins efficace).</p>
<h3 id="le-protocole-hkp">Le protocole HKP</h3>
<p>Le protocole HKP est une application particulière du protocole HTTP. Par défaut, il utilise le port TCP 11371 ou, dans sa version sécurisée par TLS (HKPS), par le port HTTPS standard 443.<sup id="fnref2"><a href="#fn2">2</a></sup></p>
<p>Il peut aussi passer par un port arbitraire, que l’on indiquera aux clients via un enregistrement SRV (<a href="https://tools.ietf.org/html/rfc2782">RFC 2782</a>) de la forme <code>_pgpkey-http._tcp.servername.example</code> (ou <code>_pgpkey-https</code> pour la version HKPS). Par exemple, l’enregistrement SRV suivant :</p>
<pre><code>_pgpkey-http._tcp.keyserver.example IN SRV 10 0 49152 server1.example
</code></pre>
<p>informera un client souhaitant utiliser le serveur <code>keyserver.example</code> qu’il doit contacter la machine <code>server1.example</code> sur le port 49152.</p>
<p>Pour rechercher et récupérer une clef, il faut demander au serveur, via une requête <code>GET</code>, une ressource de la forme <code>/pks/lookup?op=action&search=cible</code>, où action peut être <code>index</code> pour obtenir une liste des clefs correspondant au critère <code>cible</code>, ou <code>get</code> pour obtenir une clef précise.</p>
<p>Le paramètre cible sera soit un motif à rechercher dans les noms et adresses e-mails associés aux clefs, soit, s’il est précédé de <code>0x</code>, l’empreinte de la clef recherchée, sous sa forme complète (de préférence) ou tronquée aux 8 derniers octets (ce qu’on appelle « l’identifiant long » ou <em>long key ID</em>) ou aux 4 derniers octets (« l’identifiant court » ou <em>short key ID</em>).</p>
<p>Par défaut, le serveur renvoie une page HTML contenant les informations demandées ; en ajoutant le paramètre <code>options=mr</code>, le serveur renvoie une réponse sous forme de texte brut aisément analysable (<code>mr</code> signifie <em>Machine-readable</em>).</p>
<p>On peut illustrer le fonctionnement du protocole HKP en interrogeant directement un serveur depuis la ligne de commande avec des outils comme wget ou curl. Par exemple, pour chercher la clef du robot <em>Edward</em> (mis en place par la FSF dans le cadre de son initiative <a href="https://emailselfdefense.fsf.org/fr/">Autodéfense courriel</a>) :</p>
<pre><code>$ wget --quiet -O - \
'http://pool.sks-keyservers.net:11371/pks/lookup?'\
'op=index&search=edward@fsf.org&options=mr'
info:1:1
pub:F357AA1A5B1FA42CFD9FE52A9FF2194CC09A61E8:1:2048:1404075834::
uid:Edward the GPG Bot <edward@fsf.org>:1404075834::
uid:Edward, the GPG Bot <edward-en@fsf.org>:1404098786::
uid:Edward, l'amichevole bot GnuPG <edward-it@fsf.org>:1406839147::
uid:Edward, le gentil robot de GnuPG <edward-fr@fsf.org>:1404139478::
[…]
</code></pre>
<p>Les curieux pourront consulter le brouillon IETF sus-mentionné pour savoir exactement comment interpréter la réponse du serveur (section 5.2, <em>Machine Readable Indexes</em>) ; en gros, le serveur indique avoir trouvé une clef publique, et donne les caractéristiques de celle-ci et la liste des <em>User IDs</em> associées.</p>
<p>Pour rapatrier la clef trouvée :</p>
<pre><code>$ wget --quiet -O -
'http://pool.sks-keyservers.net:11371/pks/lookup?'\
'op=get&search=0x9FF2194CC09A61E8&options=mr'
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: SKS 1.1.5
Comment: Hostname: pgp.surfnet.nl
mQENBFOwfzoBCADpwK6sGC3EUzgD7IW1X5ZDR1nC5/rcXacAJLarPpvQBEz4pwjTjoAzATM7
F9RwIzJ3hJTZHiYaQY4cfiGlKSnrd8GPC8A4QkxXIaQ0hLpcsBSbtZJpo2iOzL2fRHmW2Zln
[…]
I6JWazAmnhoRyOEAld6ORPNW1EUPBsIhfazP3v5SG5NXDAjYMHH/MbX872FhoBWerfHpi1yy
ZPHSkkXIUAaY
=exlR
-----END PGP PUBLIC KEY BLOCK-----
</code></pre>
<p>Pour déposer une clef sur un serveur, on envoie une requête <code>POST</code> sur la ressource <code>/pks/add</code>, le corps de la requête, au format <code>x-www-form-urlencoded</code>, étant simplement constitué d’une variable <code>keytext</code> contenant la clef publique en « armure ASCII ».</p>
<p>Par exemple, si le fichier <code>clef.asc</code> contient une telle clef publique, on peut l’envoyer au serveur comme suit :</p>
<pre><code>$ curl --data-urlencode keytext@clef.asc \
http://pool.sks-keyservers.net:11371/pks/add
<html><body>Key block added to key server database.
New public keys added: <br>1 key(s) added successfully.</br></html></body>
</code></pre>
<h3 id="les-serveurs-publics">Les serveurs publics</h3>
<p>L’Internet renferme de quelques dizaines à quelques centaines de serveurs de clefs publics (c’est-à-dire utilisables par tout le monde, que ce soit pour y déposer une clef ou pour en rechercher une). Ils sont gérés par des volontaires, qui sont aussi bien des particuliers que des entreprises ou, souvent, des organismes de recherche ou d’enseignement supérieur (par exemple, un des plus anciens serveurs, et un des plus connus, est celui du MIT, <code>pgp.mit.edu</code>).</p>
<p>Ces serveurs se synchronisent régulièrement entre eux et le choix du serveur à interroger ou auprès duquel déposer sa clef n’a en principe pas d’importance. En fait, on évitera même, en règle générale, de référencer un serveur particulier par son propre nom (comme <code>pgp.mit.edu</code> déjà cité) : on utilisera plutôt des <em>pools</em>, des ensembles de serveurs répondant derrière un même nom DNS (à la manière des serveurs NTP du <em>NTP Pool Project</em>).</p>
<p>Le principal pool, <a href="https://sks-keyservers.net/">sks-keyservers.net</a>, rassemble les serveurs tournant sous SKS ; il est géré par Kristian Fiskerstrand (un des mainteneurs de SKS). À l’heure où j’écris ces lignes, il référence 109 serveurs, joignables derrière le nom générique <code>pool.sks-keyservers.net</code>. Des « sous-pools » permettent également de regrouper certains de ces serveurs en fonction de leur localisation géographique (ainsi, <code>eu.pool.sks-keyservers.net</code> est un pool de serveurs européens, et <code>na.pool.sks-keyservers.net</code> est un pool de serveurs nord-américains) ou de leur connectivité (ainsi, <code>ipv6.pool.sks-keyservers.net</code> ne contient que des serveurs joignables en IPv6, et <code>ha.pool.sks-keyservers.net</code> ne contient que des serveurs « à haute disponibilité »).</p>
<p>Le sous-pool <code>hkps.pool.sks-keyservers.net</code>, lui, regroupe les serveurs offrant la version TLS du protocole HKP, sur le port HTTPS standard 443. À noter, tous les serveurs de ce pool utilisent un certificat X.509 signé par une <a href="https://sks-keyservers.net/verify_tls.php">autorité de certification spécifique</a>, gérée par Kristian Fiskerstrand lui-même et exclusivement dédiée aux serveurs SKS.</p>
<p>Ceux qui souhaitent monter leur propre serveur de clefs sous SKS pourront consulter avec profit le document <a href="https://keyserver.mattrude.com/guides/building-server/">Building a PGP SKS Keyserver</a>, par Matt Rude.</p>
<h3 id="les-serveurs-ldap">Les serveurs LDAP</h3>
<p>En plus du protocole HKP, il est aussi possible d’utiliser le <a href="https://tools.ietf.org/html/rfc4511">protocole LDAP</a>. PGP Corporation, qui fut un temps l’éditeur de PGP avant son rachat par Symantec, a fourni un schéma permettant de stocker des clefs PGP dans une base LDAP ; ce schéma est aujourd’hui disponible à <a href="https://github.com/sp4ke/ldap-openpgp-keyserver/blob/master/schema/pgp-keyserver.schema">plusieurs</a><a href="https://github.com/therevmj/schema2ldif/blob/master/schema/pgp-keyserver.schema">endroits</a> sur Internet.</p>
<p>Un avantages des serveurs LDAP sur les serveurs HKP, selon l’utilisation que l’on veut faire du serveur, réside dans la possibilité de mettre en place des contrôles d’accès (ne pas autoriser n’importe qui à consulter ou modifier le contenu du serveur), ce que le protocole HKP ne permet pas.</p>
<p>Du coup, c’est une option intéressante pour un serveur que l’on veut <em>non-public</em> ou du moins <em>pas complètement public</em> : par exemple, un serveur distribuant les clefs du personnel d’une entreprise (on veut bien que tout le monde puisse y récupérer des clefs, mais seuls les membres du personnel peuvent y déposer une clef, et seulement la leur).</p>
<p>Le wiki de GnuPG contient <a href="https://wiki.gnupg.org/LDAPKeyserver">une page</a> consacrée à l’installation d’un tel serveur.</p>
<blockquote>
<p>Note</p>
<p>Une convention initiée par PGP veut que le serveur de l’entreprise Example Corporation, servant des clefs pour des adresses en <code>example.com</code>, soit accessible sous le nom <code>keys.example.com</code>. Grâce à cette convention, quand Alice veut envoyer un message à Bob (<code>bob@example.com</code>), PGP pourra récupérer automatiquement la clef de Bob en interrogeant <code>keys.example.com</code>.</p>
<p>Une variante de ce mécanisme utilise un enregistrement SRV, comme dans l’exemple suivant :</p>
<pre><code>_pgpkey-ldap._tcp.example.com. 3600 IN SRV 10 10 389 servername.example.com.
</code></pre>
<p>qui indique que les clefs pour les adresses en <code>example.com</code> peuvent être obtenues auprès du serveur servername.example.com sur le port 389.</p>
<p>Il faut noter que ces mécanismes de récupération automatique des clefs sur un serveur LDAP ne sont pas implémentés actuellement par GnuPG, même si la page de manuel dit le contraire. Personne ne semble s’être plaint de ce bug.</p>
</blockquote>
<h3 id="utilisation-avec-gnupg">Utilisation avec GnuPG</h3>
<h4 id="dirmngr">Dirmngr</h4>
<p>Depuis la version 2.1, Gpg délègue toutes les interactions avec les serveurs de clefs à Dirmngr, un démon chargé de toutes les tâches impliquant un accès réseau. Comme les autres démons auxiliaires du projet GnuPG (GPG-Agent, Scdaemon), il est automatiquement lancé par Gpg quand il est nécessaire.</p>
<p>Dirmngr utilise par défaut le pool <code>hkps.pool.sks-keyservers.net</code> déjà cité, ce qui devrait convenir à la plupart des utilisateurs qui n’ont alors pas besoin de se soucier davantage de Dirmngr.</p>
<p>Ceux qui veulent utiliser un autre serveur ou pool de serveurs devront renseigner l’option <code>keyserver</code> dans le fichier de configuration de Dirmngr, soit <code>$GNUPGHOME/dirmngr.conf</code>.<sup id="fnref3"><a href="#fn3">3</a></sup></p>
<p>Si vous choisissez d’utiliser un serveur HKPS dont le certificat n’est pas signé par une autorité de certification reconnue du système d’exploitation, vous devrez ajouter l’option <code>hkp-cacert</code> qui pointera vers un fichier contenant le(s) certificat(s) racine(s) au format PEM. Notez que ce n’est pas nécessaire pour le pool <code>hkps.pool.sks-keyservers.net</code>, dont le certificat racine est connu de GnuPG.</p>
<p>Depuis la version 2.1.10, Dirmngr peut utiliser le réseau Tor pour accéder aux serveurs de clefs (cela nécessite évidemment une installation fonctionnelle de Tor), grâce aux options suivantes :</p>
<pre><code>use-tor
keyserver hkp://jirk5u4osbsr34t5.onion
</code></pre>
<p>L’adresse <code>jirk5u4osbsr34t5.onion</code> est celle du pool de <code>sks-keyservers.net</code>.</p>
<p>Après toute modification du fichier de configuration de Dirmngr, signalez au démon de recharger sa configuration avec l’outil gpgconf :</p>
<pre><code>$ gpgconf --reload dirmngr
</code></pre>
<p>Enfin, ce n’est normalement jamais utile, mais signalons que vous pouvez communiquer directement avec Dirmngr en utilisant l’outil gpg-connect-agent. Par exemple, pour connaître le ou les serveur(s) que Dirmngr est actuellement configuré pour utiliser :</p>
<pre><code>$ gpg-connect-agent --dirmngr
> KEYSERVER
S KEYSERVER hkps://hkps.pool.sks-keyservers.net
OK
^D
</code></pre>
<p>Utilisez la commande HELP pour la liste des commandes acceptées par le démon.</p>
<h4 id="chercher-et-récupérer-une-clef">Chercher et récupérer une clef</h4>
<p>Utilisez la commande <code>--search-keys</code> de Gpg pour interroger les serveurs de clefs. Par exemple, pour chercher (à nouveau) la clef du robot Edward déjà mentionné :</p>
<pre><code>$ gpg2 --search-keys edward-fr@fsf.org
gpg: data source: https://37.191.25.53:443
(1) Edward the GPG Bot <edward@fsf.org>
Edward, the GPG Bot <edward-en@fsf.org>
Edward, l'amichevole bot GnuPG <edward-it@fsf.org>
Edward, le gentil robot de GnuPG <edward-fr@fsf.org>
2048 bit RSA key 9FF2194CC09A61E8, created: 2014-06-29
Keys 1-1 for "edward-fr@fsf.org". Enter number(s), N)ext, or Q)quit >
</code></pre>
<p>Gpg affiche la liste des clefs correspondant au motif que vous avez demandé. Si la clef que vous cherchiez s’y trouve, entrez simplement son numéro pour la télécharger et l’importer dans votre trousseau. Ici, une seule clef a été trouvée et il suffit d’entrer <code>1</code> pour la rapatrier :</p>
<pre><code>Keys 1-1 of 1 for "edward-fr@fsf.org". Enter number(s) N)ext, or Q)uit >1
gpg: key 9FF2194CC09A61E8: public key "Edward, le gentil robot de GnuPG <edward-fr@fsf.org>" imported
gpg: Total number processed: 1
gpg: imported: 1
</code></pre>
<p>Pour importer depuis les serveurs une clef dont vous connaissez déjà l’empreinte complète ou, à défaut, l’identifiant long (8 derniers octets) ou l’identifiant court (4 derniers octets), utilisez la commande <code>--receive-keys</code> (ou <code>--recv-keys</code> suivie de l’empreinte ou de l’identifiant :</p>
<pre><code>$ gpg2 --receive-keys 9FF2194CC09A61E8
</code></pre>
<p>Notez qu’il est aujourd’hui pratiquement trivial de générer une clef OpenPGP avec un identifiant court de son choix. Ces identifiants ne devraient plus être utilisés aujourd’hui. Il faut leur préférer les identifiants longs ou, mieux, les empreintes complètes.</p>
<h4 id="publier-une-clef">Publier une clef</h4>
<p>Publier une clef sur les serveurs se fait simplement via l’intermédiaire de la commande <code>--send-keys</code>, suivie de l’empreinte ou de l’identifiant (long ou court, comme d’habitude<sup id="fnref4"><a href="#fn4">4</a></sup>) :</p>
<pre><code>$ gpg2 --send-keys 9FF2194CC09A61E8
</code></pre>
<h4 id="rafraîchir-les-clefs">Rafraîchir les clefs</h4>
<p>Pour <em>rafraîchir</em> une clef déjà dans votre trousseau, c’est-à-dire obtenir la dernière version publiée de cette clef (avec toutes les éventuelles nouvelles identités, sous-clefs, et signatures), utilisez la commande <code>--refresh-keys</code>.</p>
<p>Sans arguments, cette commande rafraîchit l’intégralité du trousseau. Elle peut aussi accepter des arguments limitant les clefs à rafraîchir, soit sous la forme d’identifiants de clefs, soit d’identités (complètes ou partielles).</p>
<p>Par exemple, pour rafraîchir toutes les clefs associées à des adresses en <code>@fsf.org</code> et <code>@slackware.com</code> :</p>
<pre><code>$ gpg2 --refresh-keys @fsf.org@example.com
gpg: refreshing 2 keys from hkps://hkps.pool.sks-keyservers.net
gpg: key 9FF2194CC09A61E8: "Edward, le gentil robot de GnuPG <edward-fr@fsf.org>" not changed
gpg: key 6A4463C040102233: "Slackware Linux Project <security@slackware.com>" not changed
gpg: Total number processed: 2
gpg: unchanged: 2
</code></pre>
<h2 id="publication-des-clefs-dans-le-dns">Publication des clefs dans le DNS</h2>
<p>Au fil du temps, plusieurs méthodes ont été imaginées pour publier une clef OpenPGP dans l’arbre du DNS.</p>
<h3 id="la-méthode-moderne--dane">La méthode moderne : DANE</h3>
<p>DANE (<em>DNS-based Authentication of Named Entities</em>) est, d’après <a href="https://tools.ietf.org/wg/dane/charters?item=charter-dane-2017-02-16.txt">la charte du groupe de travail</a> du même nom à l’IETF, « un ensemble de mécanismes permettant à des applications Internet d’établir des communications cryptographiquement sûres en exploitant des informations publiées dans le DNS ». En gros, le principe est de publier des clefs cryptographiques sous des noms prévisibles dans le DNS, pour permettre leur découverte et leur récupération automatiques ; la signature des enregistrements DNS via DNSSEC apportant l’authentification nécessaire.</p>
<p>La première production du groupe DANE a été le type d’enregistrement DNS <code>TLSA</code> (<a href="https://tools.ietf.org/html/rfc6698">RFC 6698</a>), utilisé pour publier les certificats X.509 permettant d’authentifier un serveur TLS.</p>
<p>Pour OpenPGP, le groupe DANE a créé le type d’enregistrement <code>OPENPGPKEY</code>, standardisé dans le <a href="https://tools.ietf.org/html/rfc7929">RFC 7929</a>. Le standard définit notamment deux choses : où trouver l’enregistrement (le <em>owner name</em> ou <em>record name</em>, c’est-à-dire le nom de domaine associé à l’enregistrement), et ce qu’il contient (le <em>record data</em> ou <code>RDATA</code>).</p>
<p>Le <em>owner name</em> d’un enregistrement <code>OPENPGPKEY</code> est constitué comme suit :</p>
<ul>
<li>les 28 premiers octets du condensat SHA2-256 de la partie locale de l’adresse e-mail associée à la clef, représentés en hexadécimal ;</li>
<li>le composant fixe <code>_openpgpkey</code> ;</li>
<li>le domaine de l’adresse e-mail.</li>
</ul><p>Par exemple, l’enregistrement <code>OPENPGPKEY</code> pour la clef d’Alice <code><alice@example.org></code> sera situé sous le nom suivant :</p>
<pre><code>2bd806c97f0e00af1a1fc3328fa763a9269723c8db8fac4f93af71db._openpgpkey.example.org.
</code></pre>
<blockquote>
<p>Note</p>
<p>Utilisez la commande suivante pour reproduire le premier composant : <code>echo -n alice | sha256sum | cut -c1-56</code></p>
</blockquote>
<p>Le <em>RDATA</em> est simplement composé de la clef publique, sous la forme d’une série de paquets OpenPGP constituant une <em>Transferable Public Key</em> comme défini par le RFC 4880 (c’est ce que Gpg produit avec la commande <code>--export</code>). Pour minimiser la taille de l’enregistrement, il est recommandé de publier une version minimale de la clef, en supprimant : les <em>User Attributes</em> (des images que l’on peut associer à une clef, et qui supposément représentent le visage de son propriétaire), les sous-clefs expirées, les anciennes auto-certifications, et tout ou partie des certifications tierces.</p>
<p>GnuPG prend en charge le RFC 7929 depuis la version 2.1.9. D’une part, il peut récupérer automatiquement une clef publiée dans le DNS via le mécanisme générique <code>auto-key-locate</code> décrit dans une section suivante). D’autre part, il fournit l’option <code>--export-options export-dane</code> pour générer l’enregistrement OPENPGPKEY pour une clef donnée :</p>
<pre><code>$ gpg2 --export-options export-dane --export alice@example.org
$ORIGIN _openpgpkey.example.org.
; DFF9C8A3FE6663F9DD157E16F5C95C96DD4C784D
; Alice <alice@example.org>
2bd806c97f0e00af1a1fc3328fa763a9269723c8db8fac4f93af71db TYPE61 \# 4011 (
99020d045860075b011000bbe0b751b46ea0bd28a51e84702ab65efc5211e206
fccc6d272284386cd45fa2ab425601eca7058d9ef5975495ac95d3426f33fda1
[…]
2c8766621f7ddd78213e5ea500235b9a95890a98c3b394acc2d2edca98d4b619
b5f48e189b33de3a1ce0ef
)
</code></pre>
<p>La sortie produite est directement intégrable dans un fichier de zone DNS. Notez qu’elle utilise la syntaxe générique du <a href="https://tools.ietf.org/html/rfc3597">RFC 3597</a>, ce qui lui permet d’être lue par un serveur DNS ne reconnaissant pas explicitement le type <code>OPENPGPKEY</code>.<sup id="fnref5"><a href="#fn5">5</a></sup></p>
<p>Si une clef a plusieurs adresses dans des domaines différents, on peut demander à ne générer les enregistrements que pour les adresses dans un domaine donné grâce à l’option <code>--export-filter</code>. Par exemple, si la clef d’Alice est associée aux adresses <a href="mailto:alice@example.org">alice@example.org</a> et <a href="mailto:alice@other.example">alice@other.example</a>, la commande suivante permet de ne générer l‘enregistrement que pour l’adresse en example.org :</p>
<pre><code>$ gpg2 --export-options export-dane \
--export-filter "keep-uid=uid =~ example.org" \
--export alice@example.org
</code></pre>
<blockquote>
<p>Note</p>
<p>Naturellement, il serait complètement irréaliste de demander à chaque utilisateur de publier lui-même sa clef dans le DNS — ne serait-ce que parce tout le monde ne contrôle pas le domaine de son adresse e-mail. DANE pour OpenPGP ne prend tout son sens que si ce sont les fournisseurs de service de messagerie qui s’occupent de publier les clefs de leurs clients. C’est ce que propose par exemple le fournisseur <a href="https://posteo.de/en/site/encryption#posteo-keys">Posteo.de</a>.</p>
</blockquote>
<h3 id="les-méthodes-historiques">Les méthodes historiques</h3>
<h4 id="lenregistrement-cert">L’enregistrement CERT</h4>
<p>Le type d’enregistrement <code>CERT</code> est défini par le <a href="https://tools.ietf.org/html/rfc4398">RFC 4398</a> comme permettant de publier toutes sortes de clefs cryptographiques, notamment des certificats X.509 et des clefs OpenPGP.</p>
<p>Aujourd’hui, le type <code>CERT</code> est informellement déprécié et son utilisation est déconseillée <a href="https://mailarchive.ietf.org/arch/msg/openpgp/-Xi3-td6He0ZOuoh9ms_j2w7wXQ">y compris par ses inventeurs</a>, au profit des types définis par le groupe DANE (<code>TLSA</code> pour les certificats X.509, <code>OPENPGPKEY</code> pour les clefs OpenPGP).</p>
<p>Le standard définit deux « sous-types » consacrés aux clefs OpenPGP : le sous-type <code>PGP</code>, qui permet de publier une clef complète ; et le sous-type <code>IPGP</code>, qui permet de publier l’empreinte d’une clef, une URL vers la clef proprement dite, ou les deux.</p>
<p>Voici deux exemples d’enregistrements <code>CERT</code> :</p>
<pre><code>alice.example.org. IN CERT PGP 0 0 [Clef publique]
alice.example.org. IN CERT IPGP 0 0 14 [Empreinte][URL vers la clef]
</code></pre>
<h4 id="les-enregistrements-pka">Les enregistrements PKA</h4>
<p>Les enregistrements <code>PKA</code> (<em>Public Key Association</em>) ont été inventés indépendamment par les développeurs de GnuPG et n’ont jamais fait l’objet d’une standardisation. Il en existe deux versions.</p>
<p>La première version utilisait un enregistrement de type <code>TXT</code>. Le <em>owner name</em> était formé simplement en remplaçant le <code>@</code> de l’adresse e-mail par le composant <code>_pka</code> ; le <code>RDATA</code> était une chaîne de texte contenant l’empreinte de la clef ou un pointeur vers la clef elle-même, ou les deux.</p>
<p>Voici un exemple d’un tel enregistrement pour la clef d’Alice :</p>
<pre><code>alice._pka.example.org. IN TXT "v=1;fpr=DFF9C8A3FE6663F9DD157E16F5C95C96DD4C784D;uri=https://example.org/~alice/key.txt"
</code></pre>
<p>Les enregistrements <code>PKAv1</code> ne sont plus supportés depuis GnuPG 2.1.13, qui a introduit à la place les enregistrements <code>PKAv2</code>, qui diffèrent de la première version comme suit :</p>
<ul>
<li>dans le <em>owner name</em>, la partie locale de l’adresse e-mail est encodé en <a href="http://philzimmermann.com/docs/human-oriented-base-32-encoding.txt">Base32-pour-les-êtres-humains</a> ;</li>
<li>l’enregistrement est du type <code>CERT</code> décrit dans la section précédente, avec le sous-type <code>IPGP</code> ;</li>
</ul><p>Comme pour les enregistrements <code>OPENPGPKEY</code>, GnuPG peut générer un enregistrement <code>PKAv2</code> grâce à l’option <code>--export-options export-pka</code> :</p>
<pre><code>$ gpg2 --export-options export-pka --export alice@example.org
$ORIGIN _pka.example.org.
; DFF9C8A3FE6663F9DD157E16F5C95C96DD4C784D
; Alice <alice@example.org>
kei1q4tipxxu1yj79k9kfukdhfy631xe TYPE37 \# 26 0006 0000 00 14 DFF9C8A3FE6663F9DD157E16F5C95C96DD4C784D
</code></pre>
<p>Bien que toujours pris en charge par les dernières versions de GnuPG, les enregistrements <code>PKAv2</code>, non-standardisés et spécifiques à GnuPG, devraient probablement être évités en faveur du type standard <code>OPENPGPKEY</code>.</p>
<h2 id="le-protocole-openpgp-web-key-service">Le protocole OpenPGP Web Key Service</h2>
<p>Le <em>OpenPGP Web Key Service</em> (WKS) est une initiative des développeurs de GnuPG pour faciliter la distribution des clefs. Elle a été motivée, d’une part, par les problèmes bien connus des serveurs de clefs (notamment, l’absence totale de garantie qu’une clef trouvée sur un tel serveur est légitime), et d’autre part, par la lenteur du déploiement des méthodes basées sur le DNS (notamment, le faible déploiement de DNSSEC). Ce protocole est déjà implémenté par GnuPG et est <a href="https://tools.ietf.org/id/draft-koch-openpgp-webkey-service-03.txt">en cours de standardisation à l’IETF</a>.</p>
<p>Il comprend deux éléments distincts : le <em>Web Key Directory</em> (WKD) permettant de trouver automatiquement une clef à partir d’une adresse e-mail, et le <em>Web Key Directory Update Protocol</em> permettant à un utilisateur de communiquer sa clef publique à son fournisseur de messagerie.</p>
<h3 id="le-web-key-directory">Le Web Key Directory</h3>
<p>Le protocole <em>Web Key Directory</em> est assez simple et repose sur deux concepts : un enregistrement SRV (optionel) et une URI « bien connue » (<em>well-known</em>) au sens du <a href="https://tools.ietf.org/html/rfc5785">RFC 5785</a>.</p>
<p>Pour illustrer le principe, nous rechercherons la clef de, vous l’avez deviné, Alice <code><alice@example.org></code>.</p>
<p>La première étape est de demander le (ou les) enregistrement(s) associé(s) au nom <code>_openpgpkey._tcp.example.org.</code>, afin d’obtenir un nom d’hôte et un numéro de port. En l’absence d’enregistrement SRV sous ce nom, on prendra par défaut comme nom d’hôte <code>example.org</code> et comme numéro de port 443 (le port HTTPS standard).<sup id="fnref6"><a href="#fn6">6</a></sup> Ici, nous supposerons qu’il n’y a pas d’enregistrement SRV.</p>
<p>La seconde (et dernière) étape est d’envoyer une requête HTTPS à l’adresse « bien connue » suivante :</p>
<pre><code>https://example.org/.well-known/openpgkpey/hu/kei1q4tipxxu1yj79k9kfukdhfy631xe
</code></pre>
<p>La chaîne <code>kei1q4tipxxu1yj79k9kfukdhfy631xe</code> est le condensat SHA-1 de la partie locale de l’adresse e-mail (<code>alice</code>, alice), encodé en Z-Base32.<sup id="fnref7"><a href="#fn7">7</a></sup> Vous pouvez reproduire cette chaîne comme suit :</p>
<pre><code>$ echo -n alice | openssl dgst -sha1 -binary | zbase32
</code></pre>
<p>Le serveur doit renvoyer directement la clef publique d’Alice.</p>
<blockquote>
<p>Note</p>
<p>Comme pour la publication des clefs dans le DNS, il est inimaginable de demander à chaque utilisateur d’avoir son nom de domaine et son serveur web sur lequel publier sa clef. C’est au fournisseur du service de messagerie qu’il reviendra de gérer le Web Key Directory.</p>
</blockquote>
<p>GnuPG prend en charge les Web Key Directories via le mécanisme générique <code>auto-key-locate</code> décrit plus loin.</p>
<h3 id="le-web-key-directory-update-protocol">Le Web Key Directory Update Protocol</h3>
<p>Le <em>Web Key Directory Update Protocol</em> vise à permettre aux utilisateurs d’un service de messagerie de transmettre leur clef publique audit fournisseur, afin que celui-ci approvisionne son <em>Web Key Directory</em>.</p>
<p>En dépit de son nom, ce protocole n’est en réalité pas lié au concept de <em>Web Key Directory</em> : un <em>Web Key Directory</em> peut être approvisionné par d’autres moyens,<sup id="fnref8"><a href="#fn8">8</a></sup> et le protocole peut aussi servir à approvisionner d’autres systèmes de distribution de clefs (comme le DNS par exemple).</p>
<p>Le principe repose à nouveau sur une adresse « bien connue », et sur un échange d’e-mails entre l’utilisateur et son fournisseur.</p>
<p>La première étape pour le titulaire de la clef est d’obtenir l’adresse e-mail de <em>soumission de clef</em>, par une requête sur l’URL suivante (en supposant une adresse e-mail dans le domaine <code>example.org</code>) :</p>
<pre><code>https://example.org/.well-known/openpgpkey/submission-address
</code></pre>
<p>La réponse du serveur doit consister un une ligne, représentant l’adresse e-mail de soumission. La deuxième étape est d’obtenir la clef publique de chiffrement associée à cette adresse, en interrogeant soit le DNS, soit le <em>Web Key Directory</em> de <code>example.org</code>.</p>
<p>Une fois en possession de l’adresse de soumission et de la clef associée, le titulaire envoie sa propre clef par mail chiffré à l’adresse en question (les curieux pourront consulter le brouillon IETF sus-mentionné pour le détail du format du message de soumission, et de tous les messages suivants).</p>
<p>À la réception du message de soumission, le fournisseur répond par un message également chiffré (avec la clef publique qu’il vient de recevoir) et contenant un nonce.</p>
<p>Pour prouver à son fournisseur qu’il possède bien la clef privée associée à la clef publique qu’il vient de soumettre, le titulaire doit déchiffrer ce message, en extraire le nonce, et le renvoyer au serveur. Celui-ci peut alors publier la clef dans son Web Key Directory, dans le DNS, ou les deux.</p>
<p>GnuPG fournit une implémentation d’un serveur WKS (gpg-wks-server) avec <a href="https://gnupg.org/blog/20160830-web-key-service.html">les instructions</a> pour l’installer et l’intégrer à un serveur de messagerie. Le projet fournit également un client en ligne de commande (gpg-wks-client), automatisant toutes les étapes décrites ci-avant. À terme, le protocole devra être implémenté directement dans les logiciels de messagerie (nativement ou par un greffon) — il l’est déjà dans KMail, le client de messagerie de KDE, et il est en cours d’implémentation dans Enigmail, le greffon OpenPGP de Thunderbird.</p>
<h2 id="publication-dans-les-e-mails">Publication dans les e-mails</h2>
<p>Le principe de cette méthode est d’ajouter à chacun de ses e-mails, un en-tête dédié annonçant la clef de l’expéditeur.</p>
<p>Cet en-tête, appelé <code>OpenPGP</code>, peut contenir :</p>
<ul>
<li>l’empreinte de la clef (que l’on peut remplacer par son identifiant long ou son identifiant court, même si ce n’est pas une bonne idée) ;</li>
<li>une URL pointant vers la clef proprement dite ;</li>
<li>une valeur indiquant si l’expéditeur préfère recevoir des messages chiffrés, des messages signés, ou des messages chiffrés _et_signés.</li>
</ul><p>Voici un exemple d’un tel en-tête :</p>
<pre><code>OpenPGP: id=DFF9C8A3FE6663F9DD157E16F5C95C96DD4C784D;
url=https://example.org/~alice/key.txt; preference=signencrypt
</code></pre>
<p>L’en-tête <code>OpenPGP</code> est décrit dans <a href="https://www.ietf.org/archive/id/draft-josefsson-openpgp-mailnews-header-07.txt">un brouillon IETF</a> dont la dernière version a expiré en 2015, et qui n’a donc jamais atteint le stade de RFC. Il est néanmoins implémenté, au minimum, par le greffon Enigmail pour Thunderbird.</p>
<h2 id="la-découverte-automatique-des-clefs-avec-gnupg">La découverte automatique des clefs avec GnuPG</h2>
<p>Maintenant qu’on sait comment publier une clef, il reste à voir comment <em>trouver</em> trouver une clef lorsqu’on en a besoin. Nous avons déjà vu la commande <code>--search-keys</code> pour rechercher une clef sur un serveur de clefs.</p>
<p>GnuPG a introduit un mécanisme plus générique appelé <em>auto-key-locate</em>, pour obtenir automatiquement une clef à partir d’une adresse e-mail. Le but est que Bob puisse obtenir la clef d’Alice simplement avec la commande suivante :</p>
<pre><code>$ gpg2 --locate-keys alice@example.org
</code></pre>
<p>La découverte automatique des clefs se configure avec l’option <code>--auto-key-locate</code>, qui prend en paramètre une liste de mécanismes de publication de clefs à explorer. Par défaut, cette liste est vide et la découverte automatique des clefs est donc complètement désactivée. Les valeurs possibles de la liste sont :</p>
<ul>
<li>
<code>keyserver</code>, pour interroger les serveurs de clefs publics (soit la méthode historique « classique » du monde OpenPGP) ;</li>
<li>
<code>dane</code>, pour interroger le DNS à la recherche d’un enregistrement <code>OPENPGPKEY</code> (la méthode DNS moderne) ;</li>
<li>
<code>cert</code>, pour interroger le DNS à la recherche d’un enregistrement <code>CERT</code> (la méthode DNS historique standard) ;</li>
<li>
<code>pka</code>, pour interroger le DNS à la recherche d’un enregistrement PKAv2 (la méthode DNS historique propre à GnuPG) ;</li>
<li>
<code>wkd</code>, pour interroger le <em>Web Key Directory</em> du domaine de l’adresse e-mail.</li>
</ul><p>L’ordre dans lequel ces mécanismes sont spécifiés est significatif : GnuPG testera chaque mécanisme dans l’ordre indiqué jusqu’à obtenir la clef demandée. Par exemple, avec <code>--auto-key-locate dane,cert,keyserver</code>, GnuPG cherchera d’abord un enregistrement <code>OPENPGPKEY</code>, puis un enregistrement <code>CERT</code>, puis interrogera un serveur de clefs.</p>
<p>Avant toute recherche à l’extérieur, GnuPG vérifie préalablement si la clef n’est pas déjà disponible dans le trousseau local. Pour modifier ce comportement, vous pouvez utiliser les valeurs spéciales <code>nodefault</code>, qui inhibe complètement la recherche préalable dans le trousseau local, ou <code>local</code>, qui permet d’indiquer à quel moment la recherche dans le trousseau local doit avoir lieu. Par exemple, <code>--auto-key-locate nodefault,wkd</code> demande à GnuPG de ne chercher la clef demandée que dans les Web Key Directories (sans vérifier dans le trousseau local), tandis que <code>--auto-key-locate dane,local</code> lui demande de chercher d’abord dans le DNS et après seulement de vérifier dans le trousseau local.</p>
<p>Enfin, la valeur spéciale <code>clear</code> efface la liste courante des mécanismes utilisés. Elle est utile sur la ligne de commande pour ignorer ponctuellement la liste éventuellement définie dans le fichier de configuration de GnuPG.</p>
<p>Voici l’<em>auto-key-locate</em> en action :</p>
<pre><code>$ gpg2 --auto-key-locate dane,wkd --locate-key alice@example.org
gpg: key F5C95C96DD4C784D: public key "Alice <alice@example.org>" imported
gpg: Total number processed: 1
gpg: imported: 1
gpg: automatically retrieved 'alice@example.org' via DANE
</code></pre>
<blockquote>
<p>Note</p>
<p>Il s’agit d’un exemple fictif, je n’ai évidemment pas la main sur le domaine <code>example.org</code> pour y publier la clef d’Alice… Si vous voulez tester par vous-même, vous pouvez tenter de récupérer ma propre clef (associée à l’adresse <code>dgouttegattat@incenp.org</code>), qui est publiée à la fois dans le DNS et dans un <em>Web Key Directory</em>.</p>
</blockquote>
<h2 id="et-lauthentification-des-clefs">Et l’authentification des clefs ?</h2>
<p>Une question voisine de la <em>distribution</em> des clefs est celle de leur <em>authentification</em> : une fois que Bob a récupéré, via l’un des canaux décrits dans cet article, une clef prétendant appartenir à Alice, comment peut-il être sûr que c’est effectivement la sienne ?</p>
<p>Répondre à cette question est normalement le rôle du <em>modèle de confiance</em> (traité dans un <a href="//linuxfr.org/users/gouttegd/journaux/de-la-confiance-dans-le-monde-openpgp">précédent journal</a>) utilisé par Bob. On n’attend pas, en principe, du mécanisme de distribution de clefs qu’il apporte une quelconque garantie d’authenticité.</p>
<p>C’est particulièrement vrai de la distribution par l’intermédiaire des serveurs de clefs publics : tout le monde peut y déposer une clef associée à n’importe quel nom et n’importe quelle adresse e-mail, c’est à la portée de quiconque de faire <code>gpg2 --send-keys</code>.</p>
<p>En revanche, les méthodes basées sur le DNS et les Web Key Directories nécessitent, pour publier une clef, la participation (et donc le contrôle) du domaine de l’adresse e-mail associée à la clef. Ça ne constitue pas un obstacle insurmontable à la publication d’une fausse clef par un attaquant motivé, mais ça élève significativement la difficulté de la tâche.</p>
<p>En fait, dans GnuPG il était initialement prévu qu’une clef récupérée dans une zone DNS signée par DNSSEC soit automatiquement considérée comme au moins marginalement valide ; la lenteur du déploiement de DNSSEC a finalement conduit les développeurs de GnuPG à abandonner cette idée, au bénéfice du maintien de la stricte séparation entre distribution et authentification : la méthode de récupération d’une clef ne doit pas influencer le modèle de confiance.</p>
<p>Donc, dans le modèle de la toile de confiance (qui est toujours pour l’instant le modèle par défaut de GnuPG), la validité d’une clef récupérée par quelque méthode que ce soit est toujours déterminée uniquement par les certifications portées par cette clef, selon <a href="//linuxfr.org/users/gouttegd/journaux/de-la-confiance-dans-le-monde-openpgp#la-toile-de-confiance">les règles décrites</a> dans le journal cité ci-dessus.</p>
<p>À terme, le modèle de confiance par défaut devrait devenir celui de la « confiance au premier contact » (<em>Trust on First Use</em>, TOFU), où une clef fraîchement récupérée devrait se voir attribuer une validité au moins marginale, à moins que l’utilisateur n’en décide autrement.</p>
<div class="footnotes">
<hr>
<ol>
<li id="fn1">
<p>Une copie des sources (non-libres) de la version 2.5 est <a href="ftp://ftp.uni-jena.de/pub/security/PGP/utils/keyserver/keyserver.2.5.tar.asc">toujours disponible</a> pour les curieux. <a href="#fnref1">↩</a></p>
</li>
<li id="fn2">
<p>Outre le chiffrement de la communication, un avantage accessoire de HKPS par rapport à HKP est que le port HTTPS standard a moins de risque d’être bloqué par un pare-feu un peu trop restrictif que le port 11371. <a href="#fnref2">↩</a></p>
</li>
<li id="fn3">
<p>Avant la version 2.1.16, Dirmngr n’avait pas de serveur de clefs configuré par défaut, de sorte qu’il était indispensable de renseigner explicitement l’option <code>keyserver</code>. <a href="#fnref3">↩</a></p>
</li>
<li id="fn4">
<p>De manière générale, sauf mention contraire, chaque fois que le manuel de GnuPG indique qu’une commande attend un <em>identifiant de clef</em> (<em>key ID</em>), vous pouvez spécifier au choix l’empreinte complète, l’identifiant long, ou l’identifiant court. <a href="#fnref4">↩</a></p>
</li>
<li id="fn5">
<p>Le serveur Bind prend en charge le type <code>OPENPGPKEY</code> dans les fichiers de zone depuis ses versions 9.9.7 et 9.10.2. <a href="#fnref5">↩</a></p>
</li>
<li id="fn6">
<p>L’intérêt de cette indirection est que le fournisseur du service de messagerie n’a peut-être pas envie de faire fonctionner un serveur web directement sur le nom <code>example.org</code>. <a href="#fnref6">↩</a></p>
</li>
<li id="fn7">
<p>L’encodage <a href="http://philzimmermann.com/docs/human-oriented-base-32-encoding.txt">Z-Base32</a>, ou « Base32 pour les êtres humains », est une variante de l’encodage Base32 utilisant un jeu de caractères supposément plus lisible que l’ensemble [A-Z][2-7]. <a href="#fnref7">↩</a></p>
</li>
<li id="fn8">
<p>Comme mon propre <em>Web Key Directory</em>, par exemple, qui est manuellement approvisionné par mes soins (en même temps ce n’est pas dur, il ne contient qu’une seule clef, la mienne…). <a href="#fnref8">↩</a></p>
</li>
</ol>
</div><div><a href="https://linuxfr.org/users/gouttegd/journaux/de-la-distribution-des-clefs-openpgp.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/111864/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/gouttegd/journaux/de-la-distribution-des-clefs-openpgp#comments">ouvrir dans le navigateur</a>
</p>
gouttegdhttps://linuxfr.org/nodes/111864/comments.atomtag:linuxfr.org,2005:Diary/372782017-05-02T19:00:37+02:002017-05-02T19:00:37+02:00Systèmes GNU/Linux sur clé USBLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<p>Tux USB, une société française, vient de commercialiser une nouvelle clé USB avec plusieurs ISO de Linux Mint : <a href="http://www.tux-usb.com/#cle=mint">http://www.tux-usb.com/#cle=mint</a><br>
Ils ont aussi d'autres distributions de disponibles.</p><div><a href="https://linuxfr.org/users/scoubidou--2/journaux/systemes-gnu-linux-sur-cle-usb.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/111804/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/scoubidou--2/journaux/systemes-gnu-linux-sur-cle-usb#comments">ouvrir dans le navigateur</a>
</p>
NumOpenhttps://linuxfr.org/nodes/111804/comments.atomtag:linuxfr.org,2005:Post/381002017-04-27T18:09:28+02:002017-04-27T18:09:28+02:00pamusb ne déverrouille pas le trousseau de clés...<p>Bonjour à tous, </p>
<p>Je viens vers vous aujourd'hui car je viens d'installer pamusb (et d'essayer de le configurer)<br>
L'authentification par clé usb fonctionne très bien, mais lors de l'ouverture de la session graphique je dois donner le mot de passe pour déverrouiller le trousseau de clés…</p>
<p>Quelqu'un a-t-il déjà eu ce problème?</p>
<p>Merci d'avance, </p>
<p>WeeNeedYu</p><div><a href="https://linuxfr.org/forums/linux-debian-ubuntu/posts/pamusb-ne-deverrouille-pas-le-trousseau-de-cles.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/111775/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/forums/linux-debian-ubuntu/posts/pamusb-ne-deverrouille-pas-le-trousseau-de-cles#comments">ouvrir dans le navigateur</a>
</p>
WeeNeedYuhttps://linuxfr.org/nodes/111775/comments.atomtag:linuxfr.org,2005:Post/380892017-04-24T10:33:37+02:002017-04-24T10:33:37+02:00Comment retrouver une clé SSH à partir de son empreinte ?<p>Bonjour,</p>
<p>Sur mes serveurs SSH, j'autorise les connexions uniquement par clé SSH, plus par mot de passe.<br>
Par contre j'autorise encore pour le moment les connexions en tant que root.</p>
<p>Dans /var/log/auth.log (ou autre fichier de log selon la distrib) je vois des empreintes de clés associées à l'utilisateur :<br><code><br>
Apr 24 09:56:53 monserveur sshd[1350]: Accepted publickey for root from 1.2.3.4 port 42438 ssh2: RSA ef:f7:ce:5e:dd:29:c8:33:6c:b5:2a:7a:2c:8a:c7:d2<br></code>En admettant que je veuille retrouver l'utilisateur qui s'est connecté avec cette clé je peux faire un fingerprint de la clé publique des différents utilisateurs avec :<br><code><br>
ssh-keygen -lf ~/.ssh/macle.pub<br></code>Ce qui donne :<br><code><br>
2048 SHA256:ZPFqowZiS1nQJXI5com9C++pW/4M9YKFo/hA3cHtfsY moi@monposte (RSA)<br></code>Le problème c'est que le format de l'empreinte n'est pas le même sur mon poste que sur le serveur.</p>
<p>Une idée ?</p><div><a href="https://linuxfr.org/forums/linux-general/posts/comment-retrouver-une-cle-ssh-a-partir-de-son-empreinte.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/111753/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/forums/linux-general/posts/comment-retrouver-une-cle-ssh-a-partir-de-son-empreinte#comments">ouvrir dans le navigateur</a>
</p>
Adminrezohttps://linuxfr.org/nodes/111753/comments.atomtag:linuxfr.org,2005:Post/365722016-03-03T18:12:09+01:002016-03-04T22:42:39+01:00Login SSH Root impossible par clef, mais OK par password (RESOLU)<p>Voila, tout est à peu pret dans le titre, mais je vais detailler.</p>
<p>J'ai 2 serveurs en interne chez moi, je peux me connecter en ssh par mot de passe avec le compte root, le compte utilisateur_admin.</p>
<p>je peux utiliser une clef SSH avec le compte utilisateur_admin mais pas avec le compte root</p>
<p>pourtant cela me serait plus pratique car je veux pouvoir synchroniser des repertoires entre les serveurs avec <code>rsync --delete -aP $SRC $DST</code> et si possible en tant que root avec de conserver les droits, pouvoir lire des dossiers speciaux, ou les ecrire.</p>
<p>helas malgré tous mes essais, je n'y arrive pas. il continue de me demander le mot de passe.</p>
<p>je suis sur un linux CentOS 6.7, SElinux est desactivé, c'est la config ssh par defaut,<br>
j'ai fais les ssh-keygen avec clef RSA, et les ssh-copy-id entre chaque serveur.</p>
<p>et meme en mettant la clef publique de mon utilisateur depuis mon portable, dans le /root/.ssh/authorized_keys je n'arrives toujours à ma me connecter avec le clef.</p>
<p>Merci à vous pour l'aide possible.</p><div><a href="https://linuxfr.org/forums/linux-redhat/posts/login-ssh-root-impossible-par-clef-mais-ok-par-password-resolu.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/108362/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/forums/linux-redhat/posts/login-ssh-root-impossible-par-clef-mais-ok-par-password-resolu#comments">ouvrir dans le navigateur</a>
</p>
NeoXhttps://linuxfr.org/nodes/108362/comments.atomtag:linuxfr.org,2005:Post/365682016-03-02T17:25:05+01:002016-03-02T18:09:01+01:00Ma connexion wifi veut ma mort.<p>Bonjour bonjour,<br>
Tout nouveau sur linux (Easypeasy), j'ai récupéré un petit asus eeepc 901 et j'ai fait sauter xp. Or, j'essaye de me connecter en wifi, il me demande la clé je la rentre et paf c'est parti pour de nombreux refus.jusquˋà un moment ou je réussi enfin à me connecter, 15 minutes de co et ça se deconnecte :(… mon ordi passe son temps a chercher a se connecter, jai la bonne clé mais rien ny fait, à part quelque fois ou il décide d'être un peu sympa, récup un peu de bande passante et m'abandonne á nouveau.Je tiens à dire que la livebox ne m'appartient pas, je me connecte régulièrement dessus avec d'autres appareils Windows et Android.<br>
Si vous pouviez m'éclairer,ça serais gentils !</p><div><a href="https://linuxfr.org/forums/linux-debutant/posts/ma-connexion-wifi-veut-ma-mort.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/108353/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/forums/linux-debutant/posts/ma-connexion-wifi-veut-ma-mort#comments">ouvrir dans le navigateur</a>
</p>
jeweler86https://linuxfr.org/nodes/108353/comments.atomtag:linuxfr.org,2005:News/368382015-11-04T14:40:00+01:002015-11-04T14:40:00+01:00Que devient Hypra?Licence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<div><p>Hypra, c'est l'accessibilité informatique pour tous.</p>
<p>Il y a six mois (fin avril), un contributeur présentait <a href="//linuxfr.org/news/hypra-pc-a-acces-universel-et-l-accessibilite">sur ce site</a> le PC à accès universel et, du même coup, introduisait le projet Hypra dans le monde du logiciel libre. Cette dépêche a suscité pas mal de réactions ici et dans d'autres réseaux, marquant pour la plupart un soutien particulièrement précieux et encourageant pour nos équipes.</p>
<p>Il m'a paru donc naturel, en ce mois de novembre, de donner l'état d'avancement du projet en relayant le contenu de la newsletter du projet, dans une version simplifiée en texte seulement. C'est dans la deuxième partie de cette déppêche.</p></div><ul><li>lien nᵒ 1 : <a title="http://hypra.fr" hreflang="fr" href="https://linuxfr.org/redirect/95489">Le site du projet</a></li><li>lien nᵒ 2 : <a title="http://debian.org" hreflang="fr" href="https://linuxfr.org/redirect/95490">Le site de Debian</a></li><li>lien nᵒ 3 : <a title="http://hypra.fr:8080/debian/hypra-live-amd64-non-free.iso" hreflang="fr" href="https://linuxfr.org/redirect/95491">Téléchargez notre Système à Accès Universel</a></li><li>lien nᵒ 4 : <a title="http://hypra.fr/?Surconsommation-et-obsolescence" hreflang="fr" href="https://linuxfr.org/redirect/95492">Lisez notre réflexion sur le libre et l'écologie</a></li><li>lien nᵒ 5 : <a title="https://www.facebook.com/hyprasoftware/" hreflang="fr" href="https://linuxfr.org/redirect/95493">Notre compte Facebook</a></li><li>lien nᵒ 6 : <a title="https://twitter.com/HyprA11y" hreflang="fr" href="https://linuxfr.org/redirect/95494">Notre Twitter</a></li></ul><div><h2 id="quoi-de-neuf-chez-hypra">Quoi de neuf chez Hypra ?</h2>
<p>Nous sommes fiers de vous présenter notre nouveau site internet. Il est dans les liens ci-dessus. Vous y retrouverez ce qui nous anime et tout autour du PC à Accès Universel, de manière plus claire et plus directe ! Il a été internationalisé !</p>
<h2 id="le-pau">Le P.A.U</h2>
<p>Depuis avril, le PC à Accès Universel d’Hypra a fait des progrès :</p>
<ul>
<li> Synthèse vocale de meilleure qualité que celle proposée sous GNU/Linux de base ;</li>
<li> Mise en place d’un service de support et d’accompagnement à l’utilisation des logiciels ;</li>
<li> Élargissement à d’autres publics (personnes âgées, dysphasie …).</li>
</ul><p>Notre philosophie demeure : stabilité ergonomique et amélioration constante au profit de tous.</p>
<h2 id="hypra-et-la-communauté">Hypra et la communauté</h2>
<p>Hypra est heureux d’avoir pu assister, cette année, à plusieurs événements importants pour la communauté des développeurs du logiciel libre. Parmi eux, nous citerons les Rencontres Mondiales du Logiciel Libre à Beauvais, ainsi que la Debian Conference à Heidelberg, ou Alternatiba à Paris.<br>
Les rencontres que nous y avons faites nous ont permis de mieux évaluer notre positionnement dans l’écosystème du logiciel libre en tant que projet de société, nos rapports avec la communauté qui développe Debian et notre valeur ajoutée pour le grand public. La richesse de ces contacts nous a stimulé et a contribué à la maturation de ce projet.</p>
<p>Parmi les conséquences concrètes de nos échanges, nous avons décidé que tous nos développements, publics depuis leurs débuts, devaient maintenant être mis à disposition sous la forme d’un liveCD basé sur Debian en intégrant nos améliorations avant sa prochaine version stable.</p>
<h2 id="nous-retrouver">Nous retrouver</h2>
<ul>
<li>Le 17 novembre à la Fédération des Aveugles De France (F.A.F) au 6 rue Gager Gabillot 75015 Paris</li>
<li> Les 18 et 19 novembre à Paris pour l’Open-source World Summit au DOCK PULLMAN de 9h À 18h 50, av. du Président Wilson 93200 La Plaine
St-Denis</li>
<li>Le 21 novembre au Groupement des Intellectuels Ambylopes et Aveugles (G.I.A.A) de 14h à 17h 109, rue Eblé, 49100 Angers</li>
<li>Les 21 et 22 novembre à Toulouse au Capitole du Libre.</li>
</ul><h2 id="hypra-réfléchit">Hypra réfléchit</h2>
<p>À l’occasion des préparatifs de la Conference Of Parties 21 à Paris, Hypra rappelle le rôle essentiel que peuvent jouer les logiciels libres dans la construction d’un monde numérique durable.</p></div><div><a href="https://linuxfr.org/news/que-devient-hypra.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/107221/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/que-devient-hypra#comments">ouvrir dans le navigateur</a>
</p>
Texoutuiu polPierre JarillonBenoît Sibaudhttps://linuxfr.org/nodes/107221/comments.atomtag:linuxfr.org,2005:Post/359922015-10-26T10:59:08+01:002015-10-26T10:59:08+01:00Problème connexion internet<p>Bonjour à tous</p>
<p>Je suis débutant sous linux Mint et j'ai des problèmes avec ma connexion internet.<br>
J'ai une freebox et je connecte mon pc à internet grâce à une clé sfr.<br>
Internet fonctionne 20 % du temps alors que les autres ordis connectés à ce réseau fonctionnent sans problème.<br>
Il me semble avoir lu que le problème venait du fait que j'utilisais une clé mais je me perds un peu dans ce que je dois faire alors si quelqu'un pouvait m'éclairer, ce serait super.</p>
<p>Merci de votre aide</p><div><a href="https://linuxfr.org/forums/linux-debutant/posts/probleme-connexion-internet.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/107160/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/forums/linux-debutant/posts/probleme-connexion-internet#comments">ouvrir dans le navigateur</a>
</p>
zouglihttps://linuxfr.org/nodes/107160/comments.atomtag:linuxfr.org,2005:News/360242015-01-12T11:44:28+01:002016-01-22T10:32:25+01:00Compilation de logiciels libres pour Windows (janvier 2015)Licence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<div><p>Une nouvelle compilation de logiciels libres pour Windows est disponible. Plus de 60 logiciels libres ont été sélectionnés en suivant autant que possible ces critères :</p>
<ul>
<li>richesse fonctionnelle ;</li>
<li>licence(s) libre(s), de préférences copyleftées et compatibles avec les licences GNU ;</li>
<li>logiciels existants sous Windows, GNU/Linux, Mac OS X ;</li>
<li>pérennité du logiciel : développement actif, communauté importante ;</li>
<li>utilisation de langages et de bibliothèques indépendantes de Windows ;</li>
<li>version française.</li>
</ul><p><em>NdM : il faut l'acheter pour connaître la liste des logiciels libres concernés et les versions présentes ; cette liste est prévue pour évoluer.</em></p></div><ul><li>lien nᵒ 1 : <a title="https://prof-tux.fr/21-compilibre" hreflang="fr" href="https://linuxfr.org/redirect/92757">Acheter la compilation sur Prof Tux</a></li><li>lien nᵒ 2 : <a title="http://libre-shop.com/?fond=produit&id_produit=123&id_rubrique=38" hreflang="fr" href="https://linuxfr.org/redirect/92758">Acheter la compilation sur Libre-Shop</a></li><li>lien nᵒ 3 : <a title="http://compilibre.sourceforge.net" hreflang="fr" href="https://linuxfr.org/redirect/92759">COMPILIBRE</a></li><li>lien nᵒ 4 : <a title="https://www.raptor-editor.com/" hreflang="fr" href="https://linuxfr.org/redirect/92760">Raptor Editor</a></li><li>lien nᵒ 5 : <a title="https://www.reactos.org/fr" hreflang="fr" href="https://linuxfr.org/redirect/92761">ReactOS</a></li></ul><div><p>Les logiciels sont distribués avec l’installeur COMPILIBRE qui :</p>
<ul>
<li>affiche la liste des logiciels, triés par catégories ou par ordre alphabétique ;</li>
<li>affiche la description de chaque logiciel ;</li>
<li>permet de copier ou d’installer chaque logiciel sur son ordinateur, en suivant les instructions d’installation ;</li>
<li>permet de consulter le site web de chaque logiciel ;</li>
<li>affiche des documentations ou permet de les copier sur son ordinateur.</li>
</ul><p><img src="//img.linuxfr.org/img/687474703a2f2f7069782e746f696c652d6c696272652e6f72672f75706c6f61642f6f726967696e616c2f313432303838393431332e6a7067/1420889413.jpg" alt="Capture" title="Source : http://pix.toile-libre.org/upload/original/1420889413.jpg"></p>
<p>Avant d’être ajouté dans la compilation, chaque logiciel a été installé sur une version originale et à jour de Windows XP Pro et de Windows 7, dans VirtualBox. Cela a permis de vérifier les dépendances (Ghostscript, Visual C++ 2008, 2010, 2012, 2013, Java, .NET…) en 32 ou en 64 bits, de choisir les paramètres d’installation, de vérifier le bon fonctionnement du logiciel et de connaître les paramétrages indispensables avant de l’utiliser (choix de la langue par exemple). Toutes ces informations sont ajoutées dans la compilation, ce qui garantit une installation réussie des logiciels et fait gagner beaucoup de temps.</p>
<p>Si vous cherchez un prestataire pour une formation ou du développement de logiciel libre, la compilation inclut des annuaires des Entreprises du Numérique Libre (uniquement en Lorraine pour l’instant).</p>
<p>Vous pouvez acheter la compilation sur Prof Tux ou sur Libre-Shop, en téléchargement ou sur une clé USB. Cette version sera mise à jour en permanence. Il est notamment prévu de remplacer Java par OpenJDK dans les logiciels distribués.</p>
<p>Vous pouvez aussi proposer d’autres logiciels et aider à améliorer l’installeur COMPILIBRE (programmation, graphisme, traductions…). Vous pouvez aussi faire un don, ce qui permettra de rémunérer un stagiaire en développement informatique lorsqu’il y aura assez de dons. Lors du stage, il sera notamment prévu de remplacer MySQL par SQLite ou par un autre système de stockage de données plus portable, de faciliter l’internationalisation et d’intégrer Raptor Editor.</p>
<p>Si vous souhaitez avoir une compilation de logiciels libres personnalisée, écrivez à <a href="mailto:david.vantyghem@free.fr">david.vantyghem@free.fr</a>. Dans l’avenir, le système ReactOS sera aussi pris en compte.</p></div><div><a href="https://linuxfr.org/news/compilation-de-logiciels-libres-pour-windows-janvier-2015.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/104443/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/compilation-de-logiciels-libres-pour-windows-janvier-2015#comments">ouvrir dans le navigateur</a>
</p>
ScoubidouBenoît Sibaudpatrick_ghttps://linuxfr.org/nodes/104443/comments.atomtag:linuxfr.org,2005:News/359552014-12-08T21:42:31+01:002014-12-08T21:42:31+01:00Atelier SSH et clés publiques/privées le 20 décembre à CourbevoieLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<div><p>Le GULL associatif StarinuX organise l'atelier : « SSH (Secure SHell) et connexions par clés sans mot de passe » le samedi 20 décembre de 9h30 à 17h,<br>
au 48 rue de Colombes 92400 Courbevoie, salle Corail, étage 1A (SNCF : gare de Courbevoie, 7min de St Lazare et 1min de la Défense).</p>
<p>Au programme : venez vérifier vos classiques sur SSH (connexion clients / Serveur) et apprendre à se loguer en sécurité sans mot de passe via clés publique et privée.</p>
<p>Comme à l'accoutumée, une participation annuelle est demandée, de 20€ (10€ demandeurs d'emploi), valable pour plus de 15 ateliers.</p>
<p>Contact : <a href="mailto:events@starinux.org">events@starinux.org</a></p></div><ul><li>lien nᵒ 1 : <a title="http://www.starinux.org/ateliers-sx.php" hreflang="fr" href="https://linuxfr.org/redirect/92531">Informations et inscriptions</a></li><li>lien nᵒ 2 : <a title="http://www.starinux.org/" hreflang="fr" href="https://linuxfr.org/redirect/92532">Le site de l'organisateur</a></li></ul><div></div><div><a href="https://linuxfr.org/news/atelier-ssh-et-cles-publiques-privees-le-20-decembre-a-courbevoie.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/104176/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/atelier-ssh-et-cles-publiques-privees-le-20-decembre-a-courbevoie#comments">ouvrir dans le navigateur</a>
</p>
events-libreBenoît SibaudZeroHeurehttps://linuxfr.org/nodes/104176/comments.atom