tag:linuxfr.org,2005:/tags/gnupg/publicLinuxFr.org : les contenus étiquetés avec « gnupg »2022-09-20T18:50:34+02:00/favicon.pngtag:linuxfr.org,2005:Post/431512022-09-19T23:35:58+02:002022-09-19T23:35:58+02:00Libreoffice 7.4 et signature numérique via gnupg<p>Bonjour,</p>
<p>j'ai du mal à signer un document libreoffice en utilisant une clé déjà existante dans .gnupg: </p>
<ul>
<li>libreoffice ne me propose rien dans la liste des certificats disponibles lorsque je clique sur "Sign document…" ; </li>
<li>un click sur "start certificate manager" me dit qu'il ne peut pas trouver de gestionnaire de certificat, mais je ne sais pas quoi installer pour lui faire plaisir</li>
<li>tools>options>security>certificate path ne propose que des profils firefox ou thunderbird, ou alors un mode manuel pour sélectionner une base NSS, mais cela ne me dit pas comment aller piocher dans mon .gnupg !</li>
</ul>
<p>La documentation en ligne n'est pas plus utile, tout comme les forums que j'ai pu écumer.</p>
<p>Merci pour l'aiguillage à venir.</p>
<div><a href="https://linuxfr.org/forums/linux-debian-ubuntu/posts/libreoffice-7-4-et-signature-numerique-via-gnupg.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/128808/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/forums/linux-debian-ubuntu/posts/libreoffice-7-4-et-signature-numerique-via-gnupg#comments">ouvrir dans le navigateur</a>
</p>
Anonymehttps://linuxfr.org/nodes/128808/comments.atomtag:linuxfr.org,2005:News/408642022-02-06T21:58:51+01:002022-02-06T21:58:51+01:00🏆 Meilleures contributions LinuxFr.org : les primées de janvier 2022<div><p>Nous continuons sur notre lancée de récompenser celles et ceux qui chaque mois contribuent au site <em>LinuxFr.org</em> (dépêches, commentaires, logo, journaux, correctifs, etc.). Vous n’êtes pas sans risquer de gagner un livre des éditions <a href="https://www.editions-eyrolles.com/">Eyrolles</a> ou <a href="https://www.editions-eni.fr/">ENI</a>. Voici les gagnants du mois de janvier 2022 :</p>
<ul>
<li>
<em><a href="//linuxfr.org/users/gouttegd">gouttegd</a></em>, pour ses journaux « <a href="//linuxfr.org/users/gouttegd/journaux/moins-d-un-an-pour-un-vaccin-est-ce-surprenant">Moins d’un an pour un vaccin, est-ce surprenant ?</a> » et « <a href="//linuxfr.org/users/gouttegd/journaux/gnupg-devient-economiquement-viable-et-n-a-plus-besoin-de-dons">GnuPG devient économiquement viable et n’a plus besoin de dons</a> » ;</li>
<li>
<em><a href="//linuxfr.org/users/foxy">Foxy</a></em>, pour sa dépêche « <a href="//linuxfr.org/news/rfc-fast-kernel-headers-tres-prometteur-pour-le-noyau-linux">RFC Fast Kernel Headers très prometteur pour le noyau Linux</a> » ;</li>
<li>
<a href="//linuxfr.org/users/linkdd">David Delassus</a>, pour sa dépêche « <a href="//linuxfr.org/users/linkdd/journaux/letlang-encore-un-nouveau-langage-de-programmation">Letlang, encore un nouveau langage de programmation</a> » ;</li>
<li>
<em><a href="//linuxfr.org/users/karchnu/">karchnu</a></em>, pour son journal « <a href="//linuxfr.org/users/karchnu/journaux/redecouverte-roff">Redécouverte : Roff</a> » et sa dépêche « <a href="//linuxfr.org/news/get-tracks-sh-extraire-des-pistes-d-un-fichier-audio">get-tracks.sh : extraire des pistes d'un fichier audio</a> » ;</li>
<li>
<a href="//linuxfr.org/users/mynameisgnu">kevin muller</a>, pour sa dépêche « <a href="//linuxfr.org/news/passbolt-le-gestionnaire-de-mots-de-passe-pour-equipe-lance-ses-applications-mobiles">Passbolt, le gestionnaire de mots de passe pour équipe, lance ses applications mobiles</a> » ;</li>
<li>
<em><a href="//linuxfr.org/users/emmabuntus">Patrick Emmabuntüs</a></em>, pour sa dépêche « <a href="//linuxfr.org/news/sortie-de-l-emmabuntus-de4-axee-sur-le-reemploi-pour-tous-avec-ventoy">Sortie de l'Emmabuntüs DE4 axée sur le réemploi pour tous avec Ventoy !</a> ».</li>
</ul>
<p>Les livres gagnés sont détaillés en seconde partie de la dépêche. N’oubliez pas de contribuer, <em>LinuxFr.org</em> vit pour vous et par vous !</p>
</div><ul><li>lien nᵒ 1 : <a title="https://linuxfr.org/proposer-un-contenu" hreflang="fr" href="https://linuxfr.org/redirect/109856">Contribuez </a></li><li>lien nᵒ 2 : <a title="https://linuxfr.org/wiki/participer-a-linuxfr" hreflang="fr" href="https://linuxfr.org/redirect/109857">Tous les moyens (ou presque) de participer</a></li><li>lien nᵒ 3 : <a title="https://linuxfr.org/news/meilleures-contributions-linuxfr-org-les-primees-de-decembre-2021" hreflang="fr" href="https://linuxfr.org/redirect/109858">Récompenses précédentes (décembre 2021)</a></li></ul><div><h3 id="toc-les-livres--sélectionnés">Les livres 📚 sélectionnés</h3>
<ul>
<li>
<em><a href="https://www.editions-eyrolles.com/Livre/9782212138047/bases-de-donnees-orientees-graphes-avec-neo4j">Bases de données orientées graphes avec Neo4j — Manipuler et exploiter vos bases de données orientées graphes</a></em> ;</li>
<li>
<em><a href="https://www.editions-eyrolles.com/Livre/9782212678710/apprenez-a-programmer-en-python">Apprenez à programmer en Python — 3<sup>e</sup> édition</a></em> ;</li>
<li>
<em><a href="https://www.editions-eni.fr/livre/python-3-les-fondamentaux-du-langage-3e-edition-9782409020964">Python 3 — Les fondamentaux du langage — 3<sup>e</sup> édition</a></em> ;</li>
<li>
<em><a href="https://www.editions-eni.fr/livre/informatique-quantique-de-la-physique-quantique-a-la-programmation-quantique-en-q-9782409017414">Informatique quantique — De la physique quantique à la programmation quantique en Q#</a></em> ;</li>
<li>
<em><a href="https://www.editions-eni.fr/livre/langage-r-prendre-en-main-les-statistiques-complement-video-acceder-a-tous-types-de-donnees-9782409021558">Langage R — Prendre en main les statistiques</a></em>.</li>
</ul>
<p><img src="https://linuxfr.org/images/logos/logo_ski.png" alt="Bandeau LinuxFr.org"></p>
<p>Certaines personnes n’ont pas pu être jointes ou n’ont pas répondu. Les lots ont été réattribués automatiquement. N’oubliez pas de mettre une adresse de courriel valable dans votre compte ou lors de la proposition d’une dépêche. En effet, c’est notre seul moyen de vous contacter, que ce soit pour les lots ou des questions sur votre dépêche lors de sa modération. Tous nos remerciements aux contributeurs du site ainsi qu’aux éditions <a href="https://www.editions-eyrolles.com/">Eyrolles</a> et <a href="https://www.editions-eni.fr/">ENI</a>.</p>
<table>
<thead>
<tr>
<th><a href="https://www.editions-eni.fr"><img src="//img.linuxfr.org/img/68747470733a2f2f692e696d6775722e636f6d2f52464679635a642e706e67/RFFycZd.png" alt="Logo éditions ENI" title="Source : https://i.imgur.com/RFFycZd.png"></a></th>
<th> </th>
<th><a href="https://www.editions-eyrolles.com"><img src="//img.linuxfr.org/img/68747470733a2f2f692e696d6775722e636f6d2f4f3064593778552e706e67/O0dY7xU.png" alt="Logo éditions Eyrolles" title="Source : https://i.imgur.com/O0dY7xU.png"></a></th>
</tr>
</thead>
<tbody>
<tr>
<td> </td>
<td> </td>
<td> </td>
</tr>
</tbody>
</table>
</div><div><a href="https://linuxfr.org/news/meilleures-contributions-linuxfr-org-les-primees-de-janvier-2022.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/126754/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/meilleures-contributions-linuxfr-org-les-primees-de-janvier-2022#comments">ouvrir dans le navigateur</a>
</p>
Florent Zarahttps://linuxfr.org/nodes/126754/comments.atomtag:linuxfr.org,2005:Diary/400682022-01-03T01:35:15+01:002022-01-03T13:35:00+01:00GnuPG devient économiquement viable et n’a plus besoin de donsLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<h2 class="sommaire">Sommaire</h2>
<ul class="toc">
<li>
<ul>
<li><a href="#toc-lannonce">L’annonce</a></li>
<li><a href="#toc-certification-de-gnupg-pour-le-chiffrement-de-donn%C3%A9es-classifi%C3%A9es-outre-rhin">Certification de GnuPG pour le chiffrement de données classifiées outre-Rhin</a></li>
<li><a href="#toc-la-fin-de-chiasmus">La fin de Chiasmus</a></li>
</ul>
</li>
</ul>
<p>Note : Ceci est la suite du lien posté il y a quelques jours, <a href="//linuxfr.org/users/gouttegd/liens/gnupg-n-a-plus-besoin-de-vos-dons">GnuPG n’a plus besoin de vos dons</a>.</p>
<h3 id="toc-lannonce">L’annonce</h3>
<p>À la mi-décembre, le projet GnuPG a publié la dernière version de sa branche de développement, <a href="https://lists.gnupg.org/pipermail/gnupg-announce/2021q4/000468.html">GnuPG 2.3.4</a>. S’il n’y a pas grand’chose de neuf à signaler dans cette version précise (on pourra se rapporter à <a href="//linuxfr.org/news/gnupg-2-3-0-est-sorti">cette dépêche de l’année dernière</a> pour les principales nouveautés de la branche 2.3), sa publication était accompagnée d’un message pour le moins inattendu, surtout pour quiconque se souvient <a href="//linuxfr.org/news/gnupg-utilise-gnupg-oublie-mais-gnupg-finance">des difficultés financières</a> qu’a connu le projet il y a quelques années : les développeurs ont annoncé qu’ils étaient finalement en mesure d’assurer le financement du projet et n’avaient plus besoin de dons de la part des utilisateurs.</p>
<p>Et comme pour bien signifier qu’il ne s’agissait pas de paroles en l’air, ils ont aussi annoncé avoir unilatéralement annulé tous les dons récurrents mis en place via Stripe ou PayPal, et demandé aux donateurs utilisant des virements bancaires d’annuler les ordres de virement. Tous les donateurs étant invités <a href="https://twitter.com/gnupg/status/1472943158346629125">à soutenir à la place d’autres projets libres</a>.</p>
<p>Comme on peut l’imaginer, cette annonce a fait l’effet d’une bombe parmi les utilisateurs de GnuPG<sup id="fnref1"><a href="#fn1">1</a></sup>. Et les spéculations d’aller bon train<sup id="fnref2"><a href="#fn2">2</a></sup> sur ce qui a pu changer au cours des derniers mois pour permettre au projet d’atteindre la viabilité économique, les quelques mots sur l’<a href="https://gnupg.org/donate/index.html">ancienne page des dons</a> n’apportant guère d’explications.</p>
<p>Finalement, le 2 janvier 2022 Werner Koch, développeur principal de GnuPG et fondateur de g10Code GmbH (la société derrière GnuPG) s’est fendu d’<a href="https://gnupg.org/blog/20220102-a-new-future-for-gnupg.html">un billet de blog</a> expliquant la nouvelle situation du projet.</p>
<h3 id="toc-certification-de-gnupg-pour-le-chiffrement-de-données-classifiées-outre-rhin">Certification de GnuPG pour le chiffrement de données classifiées outre-Rhin</h3>
<p>Une première étape a été franchie en 2019, lorsque GnuPG a été <a href="https://media.frag-den-staat.de/files/foi/440466/BSI-VSA-10187_signed_geschwaerzt.pdf">certifié par le BSI</a><sup id="fnref3"><a href="#fn3">3</a></sup> (<em>Bundesamt für Sicherheit in der Informationstechnik</em>, <a href="https://fr.wikipedia.org/wiki/Office_f%C3%A9d%C3%A9ral_de_la_s%C3%A9curit%C3%A9_des_technologies_de_l%27information">office fédéral pour la sécurité des technologies de l’information</a>, l’équivalent allemand de l’<a href="https://fr.wikipedia.org/wiki/Agence_nationale_de_la_s%C3%A9curit%C3%A9_des_syst%C3%A8mes_d%27information">ANSSI</a>) pour le chiffrement de données classifiées au niveau Vs-NfD (<em>Verschlusssache-Nur für Dienstgebrauch</em>, équivalent au niveau français <em>Diffusion restreinte</em> et au niveau OTAN <em>Restricted</em>).</p>
<p>Détail important, si le BSI a certifié un variant particulier de GnuPG (sous le nom <em>Gpg4VS-NfD</em>), tous les changements apportés à GnuPG pour le rendre certifiable sont disponibles dans la version publique, libre, de GnuPG. En fait, la version certifiée <em>Gpg4VS-NfD</em> n’est rien d’autre que la version standard de GnuPG telle qu’on peut la trouver sur gnupg.org, qui est simplement pré-configurée pour être par défaut conforme aux exigences du BSI (option <code>--compliance de-vs</code>).</p>
<p>Une fois la certification obtenue, les développeurs ont entrepris de « faire de <em>Gpg4VS-NfD</em> un véritable produit [commercial] » (et non plus un simple <em>build</em> seulement destiné à être présenté aux évaluateurs du BSI), renommé pour l’occasion en <em>GnuPG VS-Desktop</em> et vendu via le site gnupg.com.</p>
<p>Comme le <em>Gpg4VS-NfD</em> dont il est dérivé, <em>GnuPG VS-Desktop</em> est construit depuis exactement le même code source que celui diffusé sur gnupg.org sous licence Gnu GPL. Il n’est pas question ici d’un modèle <em>open core</em> ou assimilé, où la version payante <em>GnuPG VS-Desktop</em> fournirait des fonctionnalités qui feraient défaut à la version « communautaire » <em>GnuPG</em>.</p>
<p>Le modèle économique derrière <em>GnuPG VS-Desktop</em> (ou la réponse à la question « pourquoi diable des gens voudraient-ils payer pour un logiciel librement et gratuitement disponible par ailleurs ?) repose, de manière somme toute assez prévisible dans le monde du libre, sur la vente de contrats de support et de développements sur-mesure.</p>
<p>La certification du BSI est aussi un avantage non-négligeable de <em>GnuPG VS-Desktop</em> par rapport à GnuPG, du moins pour certains clients allemands. Et justement, c’est là qu’intervient le petit coup de pouce du destin qui assure aujourd’hui à GnuPG sa viabilité économique.</p>
<h3 id="toc-la-fin-de-chiasmus">La fin de Chiasmus</h3>
<p>Depuis des années, le logiciel utilisé en Allemagne pour le chiffrement au niveau VS-NfD était <a href="https://www.bsi.bund.de/EN/Topics/Cryptography/Chiasmus/Chiasmus_node.html">Chiasmus</a>, produit et distribué par le BSI (pas sous licence libre ; son utilisation n’était autorisée que si elle était « dans l’intérêt de la République fédérale d’Allemagne »). Il utilise un algorithme de chiffrement maison, appelé lui aussi CHIASMUS, jamais publiquement documenté par le BSI mais dont les détails ont été <a href="https://fahrplan.events.ccc.de/congress/2013/Fahrplan/events/5307.html">obtenus par rétro-ingénierie</a>.</p>
<p>Or dernièrement, il est apparu que le BSI n’avait plus vraiment confiance dans son propre logiciel. Sa certification VS-NfD n’est valable que jusqu’au 30 juin 2022, et ne sera pas renouvelée. Il n’est déjà plus possible d’en demander une copie auprès du BSI.</p>
<p>Le retrait de Chiasmus signifie que tous ses utilisateurs (tous ceux qui manipulent des données au niveau VS-NfD) doivent maintenant <a href="https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Crypto/Chiasmus_replacement_guide.pdf?__blob=publicationFile&v=2">chercher une alternative</a>. Et ils n’ont le choix qu’entre deux options, deux logiciels ayant la certification VS-NfD : <a href="https://www.cryptovision.com/de/produkte/sichere-verschluesselung/greenshield/">GreenShield</a> de CryptoVision (propriétaire), et… <em>GnuPG VS-Desktop</em> de g10Code (libre).</p>
<p>Or, les utilisateurs de Chiasmus, ce sont non seulement la quasi-totalité des institutions et agences gouvernementales allemandes, mais aussi toutes les sociétés privées et acteurs libéraux qui doivent interagir avec ces institutions et agences. Même si une partie d’entre eux choisiront sans doute la solution propriétaire de CryptoVision, les commerciaux de g10Code estiment aujourd’hui qu’environ 250 000 lieux de travail utiliseront GnuPG VS-Desktop.</p>
<p>Voilà donc d’où provient la manne financière qui assure aujourd’hui à GnuPG sa pérennité. Un modèle économique somme toute classique pour du logiciel libre, mais facilité par le besoin impérieux de certains utilisateurs institutionnels (ou des utilisateurs en relation avec des utilisateurs institutionnels) pour un logiciel <em>certifié</em>.</p>
<div class="footnotes">
<hr>
<ol>
<li id="fn1">
<p>Ou pas, en vrai. Le tweet du compte @GnuPG annonçant la fin du recours aux dons semble avoir eu un impact pour le moins limité (15 <em>retweets</em> et 64 <em>likes</em>, alors que le compte a 20.5K <em>followers</em>). L’annonce n’a suscité aucune réaction sur les listes de discussion du projet. Et la seule mention sur DLFP est <a href="//linuxfr.org/users/gouttegd/liens/gnupg-n-a-plus-besoin-de-vos-dons">celle de votre serviteur</a>, qui d’ailleurs n’écrit ce journal que pour tenter de donner raison à sa propre affirmation selon laquelle l’annonce a fait l’effet d’une bombe, alors que selon toute vraisemblance tout le monde s’en moque comme de sa première clef DSA. <a href="#fnref1">↩</a></p>
</li>
<li id="fn2">
<p>Rien que sur DLFP, au moins trois personnes ont été vues se livrer à des spéculations acharnées s’étalant sur cinq messages. Une bombe, je vous dis. <a href="#fnref2">↩</a></p>
</li>
<li id="fn3">
<p>Document semble-t-il disponible en allemand uniquement, du moins c’est tout ce que j’ai trouvé. De manière générale, toute cette histoire est très germano-germanique, et les lecteurs désireux d’en savoir encore plus auront tout intérêt à connaître la langue de Goethe. <a href="#fnref3">↩</a></p>
</li>
</ol>
</div>
<div><a href="https://linuxfr.org/users/gouttegd/journaux/gnupg-devient-economiquement-viable-et-n-a-plus-besoin-de-dons.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/126428/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/gouttegd/journaux/gnupg-devient-economiquement-viable-et-n-a-plus-besoin-de-dons#comments">ouvrir dans le navigateur</a>
</p>
gouttegdhttps://linuxfr.org/nodes/126428/comments.atomtag:linuxfr.org,2005:Bookmark/40342021-12-27T19:13:09+01:002021-12-27T19:13:09+01:00GnuPG n’a plus besoin de vos dons<a href="https://gnupg.org/donate/index.html">https://gnupg.org/donate/index.html</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/126379/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/gouttegd/liens/gnupg-n-a-plus-besoin-de-vos-dons#comments">ouvrir dans le navigateur</a>
</p>
gouttegdhttps://linuxfr.org/nodes/126379/comments.atomtag:linuxfr.org,2005:Diary/397632021-05-10T19:36:16+02:002021-05-11T08:14:38+02:00Ma redécouverte de GPGLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<p>Hello,</p>
<p>Je me permets d'écrire ce journal tel un mémo technique sur mon utilisation relativement basique de GPG, mais également comme un appel à la correction de ce que je n'aurais pas ou mal compris.</p>
<p>J'ai personnellement découvert GPG lors de ma fin d'étude (encore relativement proche), avec le logiciel <a href="https://www.passwordstore.org/">pass</a>. En effet <code>pass</code> nécessite l'utilisation d'une clef GPG pour le chiffrement de ses données. A l'époque j'étais tombé sur l'article de <a href="https://alexcabal.com/creating-the-perfect-gpg-keypair">alexcabal</a> que j'avais jugé pertinent et que j'avais suivi plus ou moins à la lettre sans plus de réflexion.</p>
<p>Un certain temps plus tard, j'ai souhaité revoir mon usage complètement casual de Git, et en souhaitant m'améliorer sur ce sujet, j'ai découvert le principe de <em>signature</em> de commit par clef GPG. J'ai donc décidé de créer une nouvelle clef GPG<br>
afin de l'utiliser en tant que signature sur mes projets pro, et encore une autre clef pour mes projets perso (oui, on va en reparler de ces clefs).</p>
<p>Bref, me voici quelques années plus tard sans avoir véritablement réutilisé GPG, sur le point de quitter mon entreprise pour une autre. Et c'est donc logiquement qu'il va me falloir générer une nouvelle clef pour mon nouvel emploi, mais également une seconde pour mon nouvel email personnel (au revoir Google).</p>
<p>Pour me dépoussiérer un peu sur le sujet je me rends en premier lieu sur linuxfr.org (mais pas que), je fouille un peu et je dévore tous les articles suivants :</p>
<p>GPG en large en long en travers sur linuxfr.org :<br>
- <a href="//linuxfr.org/news/bien-demarrer-avec-gnupg">https://linuxfr.org/news/bien-demarrer-avec-gnupg</a><br>
- <a href="//linuxfr.org/users/gouttegd/journaux/de-la-gestion-des-clefs-openpgp">https://linuxfr.org/users/gouttegd/journaux/de-la-gestion-des-clefs-openpgp</a> <br>
- <a href="//linuxfr.org/news/gpg-les-concepts-en-clair-et-pedagogiquement">https://linuxfr.org/news/gpg-les-concepts-en-clair-et-pedagogiquement</a></p>
<p>Ces trois articles à eux seuls sont une mine d'or qui m'ont énormément éclaircie ma lanterne, et je recommande d'ailleurs de lire les commentaires de ces trois articles qui fourmillent de questions et de remarques pertinentes.</p>
<p>La signature de commit sur git-scm/github/gitlab :<br>
- <a href="https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work">https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work</a><br>
- <a href="https://docs.github.com/en/github/authenticating-to-github/generating-a-new-gpg-key">https://docs.github.com/en/github/authenticating-to-github/generating-a-new-gpg-key</a><br>
- <a href="https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/">https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/</a></p>
<p>Et enfin plusieurs articles sur les best-practices et notamment l'utilisation des Subkeys :<br>
- <a href="https://wiki.debian.org/subkeys">https://wiki.debian.org/subkeys</a><br>
- <a href="https://gist.github.com/Integralist/f7e17034800b65b51eb7e9807720025a">https://gist.github.com/Integralist/f7e17034800b65b51eb7e9807720025a</a><br>
- <a href="https://blog.eleven-labs.com/en/openpgp-almost-perfect-key-pair-part-1/">https://blog.eleven-labs.com/en/openpgp-almost-perfect-key-pair-part-1/</a><br>
- <a href="https://gist.github.com/Integralist/f7e17034800b65b51eb7e9807720025a">https://gist.github.com/Integralist/f7e17034800b65b51eb7e9807720025a</a></p>
<p>Après avoir lu ce contenu, je suis resté cependant perplexe sur certains détails, et notamment ce concept de <em>trust</em> et d'identité, je ne comprenais pas comment gérer aussi facilement plusieurs identités avec plusieurs clefs qui évoluent au cours de la vie. Long story short, je suis finalement tombé sur <a href="https://www.bortzmeyer.org/nouvelle-cle-pgp.html">l'article de Bortzmeyer</a> dans <a href="//linuxfr.org/nodes/105773/comments/1604606">un commentaire</a>, qui parle justement des identités. Il semble que j'étais à côté de la plaque pendant plusieurs années.</p>
<p>Donc après avoir fait le ménage dans mon <code>~/.gnupg</code> je me retrouve avec une seule clef principale contenant toutes mes identités, et je (pense?) avoir maintenant compris les bases de GnuPG. Prochaine étape, les mails chiffrés :)</p>
<p>Ah non j'allais oublier un problème ! J'ai eu un mal fou pour changer la clef utilisée pour <code>pass</code>, et n'obtenais que des</p>
<pre><code>gpg: 878AED67: skipped: Unusable public key
</code></pre>
<p>Jusqu'à ce que je tombe sur le mot clef <code>usage</code>:</p>
<pre><code>gpg --edit-key --expert name@domain.tld
sec ed25519/0xABC1234567890
created: 2021-05-10 expires: 2023-05-10 usage: SC
trust: ultimate validity: ultimate
ssb ed25519/0x0987654321DEF
created: 2021-05-10 expires: 2023-05-10 usage: S
</code></pre>
<p>J'ai rapidement fait le lien avec <code>SC = sign capability</code> et <code>S = sign only</code>. Et je me suis rendu compte qu'il me manquait donc une clef de Chiffrement (<code>usage: E</code> pour <code>Encrypt</code>). Je n'ai pas vérifié cela plus tôt car j'avais pu lire sur plusieurs sources qu'à la génération d'une clef principale, on obtenait automatiquement une subkey de chiffrement, mais il semble que cela ne soit plus le cas, où que j'ai raté quelque chose.</p>
<div><a href="https://linuxfr.org/users/nox/journaux/ma-redecouverte-de-gpg.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/124238/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/nox/journaux/ma-redecouverte-de-gpg#comments">ouvrir dans le navigateur</a>
</p>
noxhttps://linuxfr.org/nodes/124238/comments.atomtag:linuxfr.org,2005:News/398682020-05-23T20:49:36+02:002020-06-01T18:39:58+02:00Bien démarrer avec GnuPGLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<div><p><em>N. D. M. : la dépêche est tirée du journal personnel de l’auteur, complétée des premiers commentaires suscités.</em></p>
<p>Suite à une diatribe de ma part à l’encontre de la mauvaise qualité de beaucoup de tutoriels consacrés à GnuPG, <a href="//linuxfr.org/forums/general-general/posts/gpg-2-postes-et-1-yubikey#comment-1805704">on m’a suggéré</a> de créer le mien. Alors, <em>without further ado</em>, le voici.</p>
</div><ul><li>lien nᵒ 1 : <a title="https://linuxfr.org/users/gouttegd/journaux/bien-demarrer-avec-gnupg" hreflang="fr" href="https://linuxfr.org/redirect/106347">Journal à l’origine de la dépêche</a></li><li>lien nᵒ 2 : <a title="https://gnupg.org/" hreflang="en" href="https://linuxfr.org/redirect/106348">Site de GnuPG</a></li><li>lien nᵒ 3 : <a title="https://incenp.org/dvlpt/docs/carte-openpgp/index.html" hreflang="fr" href="https://linuxfr.org/redirect/106350">Blog de l’auteur : la carte OpenPGP</a></li></ul><div><h2 class="sommaire">Sommaire</h2>
<ul class="toc">
<li><a href="#toc-installation-de-gnupg">Installation de GnuPG</a></li>
<li><a href="#toc-g%C3%A9n%C3%A9rer-sa-clef">Générer sa clef</a></li>
<li>
<a href="#toc-que-faire-apr%C3%A8s-avoir-cr%C3%A9%C3%A9-sa-clef">Que faire après avoir créé sa clef ?</a><ul>
<li><a href="#toc-sauvegarder-les-clefs">Sauvegarder les clefs</a></li>
<li><a href="#toc-mettre-%C3%A0-labri-le-certificat-de-r%C3%A9vocation">Mettre à l’abri le certificat de révocation</a></li>
</ul>
</li>
<li>
<a href="#toc-diffuser-la-clef-publique">Diffuser la clef publique</a><ul>
<li><a href="#toc-les-serveurs-de-clefs-sks">Les serveurs de clefs SKS</a></li>
<li><a href="#toc-le-serveur-keysopenpgporg">Le serveur keys.openpgp.org</a></li>
<li><a href="#toc-autres-m%C3%A9thodes-de-distribution">Autres méthodes de distribution</a></li>
</ul>
</li>
<li>
<a href="#toc-chiffrer-signer-des-fichiers">Chiffrer, signer des fichiers</a><ul>
<li><a href="#toc-chiffrer-un-fichier">Chiffrer un fichier</a></li>
<li><a href="#toc-signer-un-fichier">Signer un fichier</a></li>
<li><a href="#toc-d%C3%A9chiffrer-v%C3%A9rifier-un-fichier">Déchiffrer, vérifier un fichier</a></li>
</ul>
</li>
<li>
<a href="#toc-chiffrer-signer-des-courriels">Chiffrer, signer des courriels</a><ul>
<li><a href="#toc-obtenir-la-clef-dedward">Obtenir la clef d’Edward</a></li>
<li><a href="#toc-thunderbird-et-enigmail">Thunderbird et Enigmail</a></li>
<li><a href="#toc-neomutt">(Neo)Mutt</a></li>
<li><a href="#toc-autres-clients">Autres clients</a></li>
</ul>
</li>
<li><a href="#toc-comment-changer-la-date-dexpiration-de-saclef">Comment changer la date d’expiration de sa clef ?</a></li>
<li><a href="#toc-utilisation-dans-un-logiciel-ne-prenant-pas-en-charge-gpg">Utilisation dans un logiciel ne prenant pas en charge GPG</a></li>
</ul>
<h2 id="toc-installation-de-gnupg">Installation de GnuPG</h2>
<p>Si vous utilisez GNU/Linux, GnuPG est dans les dépôts de toutes les distributions, et il est très souvent installé par défaut.</p>
<p>Il peut être utile néanmoins de vérifier que la version installée est bien issue de la dernière branche stable (2.2.x), et non de la branche 1.4.x (qui n’est maintenue que pour la compatibilité avec les versions de PGP datant des années 1990) ou des branches 2.0.x/2.1.x (qui sont obsolètes).</p>
<p>Il est possible de faire cohabiter GnuPG 1.4 et GnuPG 2.2 sur le même système ; dans ce cas, assurez‑vous que la version que vous utilisez en temps normal est bien la 2.2.</p>
<p>En 2020, il semble que sur la plupart des distributions GNU/Linux, demander l’installation d’un paquet <em>gnupg</em> installe bien GnuPG 2.2, le binaire correspondant étant disponible sous le nom <code>gpg</code>. Il y a quelques exceptions, comme Fedora, où <em>gnupg</em> installe GnuPG 1.4 — il faut demander l’installation de <em>gnupg2</em> pour avoir GnuPG 2.2, le binaire correspondant étant appelé <code>gpg2</code>.</p>
<blockquote>
<p>Dans le reste de cet article, je supposerai que <code>gpg</code> est le binaire de GnuPG 2.2 ; remplacez <code>gpg</code> par <code>gpg2</code> si besoin, en fonction de votre distribution.</p>
</blockquote>
<p>Sous Windows, <a href="https://gpg4win.org/download.html">Gpg4Win</a> est la distribution GnuPG de référence. La version 3.1.11, à l’heure où ces lignes sont écrites, fournit GnuPG 2.2.17.</p>
<p>Sous macOS, <a href="https://gpgtools.org/">GPG Suite</a> est une distribution fournissant GnuPG 2.2.17. GnuPG est aussi disponible via <a href="https://www.macports.org/">MacPorts</a>, sous le nom <em>gnupg2</em>.</p>
<h2 id="toc-générer-sa-clef">Générer sa clef</h2>
<p>Étape incontournable, la génération de la clef est malheureusement l’objet d’un volume considérable de désinformation. C’est l’étape où la plupart des « tutos » consacrés à GnuPG se fourvoient, et noient l’aspirant utilisateur sous une foule de « conseils » mal avisés, inutiles voire dangereux.</p>
<p>Alors, une bonne fois pour toutes : générer une clef, ça se fait en une seule étape, une seule commande :</p>
<pre><code>$ gpg --gen-key
GnuPG doit construire une identité pour identifier la clef.
Nom réel : Alice
Adresse électronique : alice@example.org
Vous avez sélectionné cette identité :
"Alice <alice@example.org>"
Changer le (N)om, l’(A)dresse électronique ou (O)ui/(Q)uitter ? o
De nombreux octets aléatoires doivent être générés. Vous devriez faire
autre chose (taper au clavier, déplacer la souris, utiliser les disques)
pendant la génération de nombres premiers ; cela donne au générateur de
nombres aléatoires une meilleure chance d’obtenir suffisamment d’entropie.
gpg: clef 54B4CC7749CAE7C3 marquée de confiance ultime
gpg: revocation certificate stored as '/home/alice/.gnupg/openpgp-revocs.d/7685DC4214D727BB011BD6B754B4CC7749CAE7C3.rev'
les clefs publique et secrète ont été créées et signées.
pub rsa2048 2020-05-13 [SC] [expires: 2022-05-13]
7685DC4214D727BB011BD6B754B4CC7749CAE7C3
uid Alice <alice@example.org>
sub rsa2048 2020-05-13 [E]
</code></pre>
<p>Oui, c’est tout. Ça n’a pas besoin d’être plus compliqué que ça. Non, il n’est pas nécessaire d’ajouter préalablement trente‐cinq lignes dans le fichier de configuration de GnuPG pour changer les réglages par défaut. <em>La configuration par défaut de GnuPG est saine !</em> Les réglages par défaut ont été choisis comme tels pour de bonnes raisons. Vous ne devriez y toucher que si vous savez exactement <em>pourquoi</em> ils ne conviendraient pas à votre cas d’utilisation — pas parce qu’un <em>crypto‑nerd</em> vous dit de le faire dans son billet de blog « générer une clef parfaite en dix‑sept étapes ».</p>
<p>À quoi ressemble une clef générée en suivant les réglages par défaut ? C’est une clef principale RSA de 2 048 bits, destinée aux opérations de signature, et une sous‑clef de chiffrement similaire. Elle a une durée de validité de deux ans à compter de sa création, et est associée aux préférences d’algorithmes suivantes :</p>
<ul>
<li>pour le chiffrement : AES256, puis AES192, AES128 et 3DES ;</li>
<li>pour la condensation : SHA2‑512, puis SHA2‑384, SHA2‑256, SHA2‑224 et SHA‑1 ;</li>
<li>pour la compression : ZLIB, puis BZIP2, ZIP, pas de compression.</li>
</ul>
<p>Une fois encore, ces préférences par défaut (qui ne datent pas d’hier — la plupart de ces réglages datent de 2009 ou 2010) sont saines et n’ont pas besoin d’être modifiées.</p>
<p>Éventuellement, si l’idée d’une clef RSA de 2 048 bits vous fait tiquer (ça ne devrait pas) et si vous êtes sûrs que vos correspondants utilisent tous des implémentations suffisamment modernes d’OpenPGP, vous pouvez opter pour une clef utilisant l’algorithme par défaut des prochaines versions de GnuPG<sup id="fnref1"><a href="#fn1">1</a></sup> :</p>
<pre><code>$ gpg --quick-gen-key 'Robert <bob@example.org>' future-default
Sur le point de créer une clef pour :
"Robert <bob@example.org>"
Faut-il continuer ? (O/n) o
De nombreux octets aléatoires doivent être générés. Vous devriez faire
autre chose (taper au clavier, déplacer la souris, utiliser les disques)
pendant la génération de nombres premiers ; cela donne au générateur de
nombres aléatoires une meilleure chance d’obtenir suffisamment d’entropie.
gpg: clef AC44CDC5733527A9 marquée de confiance ultime
gpg: revocation certificate stored as '/home/bob/.gnupg/openpgp-revocs.d/D7D0521F44673693DFFEB13FAC44CDC5733527A9.rev'
les clefs publique et secrète ont été créées et signées.
pub ed25519 2020-05-13 [SC] [expires: 2022-05-13]
D7D0521F44673693DFFEB13FAC44CDC5733527A9
uid Robert <bob@example.org>
sub cv25519 2020-05-13 [E]
</code></pre>
<p>Pous obtenez alors une clef principale de signature de type <a href="https://fr.wikipedia.org/wiki/EdDSA">Ed25519</a> et une sous‑clef de chiffrement de type <code>cv25519</code> ; comme leur nom le laisse supposer, ces clefs sont basées sur la courbe elliptique dite « <a href="https://fr.wikipedia.org/wiki/Curve25519">25519</a> » (<a href="https://tools.ietf.org/html/rfc7748">RFC 7748</a>).</p>
<blockquote>
<p>La courbe 25519 ne fait pas encore partie du standard OpenPGP, qui officiellement ne prend en charge pour l’instant que les courbes P‑256, P‑384, et P‑521 du NIST (<a href="https://tools.ietf.org/html/rfc6637">RFC 6637</a>). Elle a néanmoins été ajoutée dès les premiers brouillons du RFC « 4880bis » (la prochaine version du standard) en 2016 et peut être utilisée dès maintenant sans crainte pour la compatibilité future.</p>
<p>En pratique, la courbe 25519 est gérée par la plupart des implémentations d’OpenPGP — à ma connaissance, au moins GnuPG (≥ 2.1), OpenPGP.js, Sequoia-PGP, et RNP. Déterminer si elle est prise en charge par « Broadcom Encryption Desktop » (héritier de Symantec PGP), en dénichant des informations techniques au milieu des arguments commerciaux de Broadcom, est laissé en exercice au lecteur.</p>
<p>Concrètement, vous ne devriez pas rencontrer de problèmes si vous choisissez d’utiliser l’option <code>future-default</code>, à moins que certains de vos correspondants n’utilisent toujours GnuPG ≤ 2.0 — auquel cas, essayez de les convaincre de se mettre à jour, ce sera beaucoup plus productif que de suivre un tutoriel vous recommandant de générer une clef RSA de 8 192 bits.</p>
</blockquote>
<p>Bien entendu, si la ligne de commande vous rebute, il est parfaitement possible de s’en passer. La manière exacte de générer une clef peut varier légèrement d’un frontal GnuPG à un autre (GPA, Seahorse, KGpg, etc.), mais les grandes lignes restent les mêmes et sont illustrées dans la suite.</p>
<blockquote>
<p>Dans le reste de cet article, je privilégierai la ligne de commande aux frontaux graphiques. Nul élitisme de ma part, c’est simplement que l’interface en ligne de commande est la même partout, alors que chaque frontal a sa propre interface et qu’il n’est pas réaliste de les présenter tous — je reparlerai parfois de GPA parce que c’est le frontal que j’utilise, mais pour les autres, je vous renvoie à leur documentation.</p>
</blockquote>
<p><img src="//img.linuxfr.org/img/68747470733a2f2f696e63656e702e6f72672f66696c65732f6d6973632f323032302f6770612d6b657967656e2e706e67/gpa-keygen.png" alt="Fig. 1" title="Source : https://incenp.org/files/misc/2020/gpa-keygen.png"> <em><strong>Figure 1</strong> — Les quatre étapes pour créer une clef avec GNU Privacy Assistant (GPA), le frontal officiel de GnuPG : saisissez votre nom <strong>(A)</strong>, votre adresse de courriel <strong>(B)</strong>, choisissez si vous voulez une copie de sauvegarde de votre future clef <strong>(C)</strong>, observez votre clef nouvellement créée <strong>(D)</strong>.</em></p>
<h2 id="toc-que-faire-après-avoir-créé-sa-clef">Que faire après avoir créé sa clef ?</h2>
<h3 id="toc-sauvegarder-les-clefs">Sauvegarder les clefs</h3>
<p>Sauf contraintes très particulières, vos clefs <em>doivent</em> être sauvegardées ; n’en gardez qu’une seule copie sur la machine où elles ont été créées et sont utilisées, c’est courir le risque de les perdre (et avec elles, les données dont elles dépendent) le jour où le disque dur rend l’âme ou la machine est perdue ou volée.</p>
<blockquote>
<p>S’il est possible d’adopter pour les clefs publiques une stratégie de sauvegarde torvaldienne (<em>c.‐à‐d.</em> les « mettre sur un serveur FTP et laisser le reste du monde en faire des miroirs »), ce n’est évidemment pas le cas des clefs privées…</p>
</blockquote>
<p>Vous pourriez être tenté de faire une simple archive du dossier <code>.gnupg</code>, qui contient tous les fichiers manipulés par GnuPG (dont les trousseaux). Toutefois, ce n’est pas nécessairement une bonne idée : le contenu exact de ce dossier est considéré comme un détail d’implémentation interne à GnuPG, qui à ce titre est susceptible de changer au fil des versions (par exemple, la manière de stocker les clefs sur le disque a radicalement changé entre GnuPG 2.0 et GnuPG 2.1). Il est préférable de n’utiliser que l’interface publique de GnuPG, qui générera un fichier au format standard OpenPGP, dont il est garanti qu’il sera lisible par n’importe quelle version future de GnuPG (ou par une autre implémentation conforme du standard, indépendante de GnuPG).</p>
<p>Comme entr’aperçu en figure 1, si vous avez créé vos clefs avec GPA, vous avez pu choisir de créer automatiquement une copie de sauvegarde dès le début. Sinon, utilisez la commande suivante pour créer une telle copie :</p>
<pre><code>$ gpg -o backup.gpg --export-secret-keys alice@example.org
</code></pre>
<p>Contrairement à ce que le nom de la commande <code>--export-secret-keys</code> peut laisser supposer, le fichier <code>backup.gpg</code> ne contient pas que la partie secrète des clefs, mais aussi tous les éléments qui composent la clef publique. Ce fichier est donc suffisant à lui seul pour restaurer l’intégralité de vos clefs.</p>
<blockquote>
<p>Plus tard, lorsque vous aurez commencé à utiliser GnuPG pour échanger avec vos correspondants, vous aurez à sauvegarder deux éléments supplémentaires : les clefs publiques de vos correspondants et la confiance que vous leur accordez. Vous pouvez utiliser pour ça les deux commandes suivantes :</p>
<pre><code>$ gpg -o public-keys.gpg --export
$ gpg --export-ownertrust > trust.txt
</code></pre>
</blockquote>
<p>Ce que vous faites ensuite de votre copie de sauvegarde est de votre ressort. Notez qu’elle contient vos clefs privées sous leur forme protégée par votre phrase de passe (sauf si vous avez choisi de ne pas avoir de phrase de passe lors de la création de la clef). Donc, pour peu que ladite phrase de passe soit assez robuste, quiconque mettrait la main sur votre sauvegarde ne serait pas pour autant en mesure d’utiliser vos clefs.</p>
<blockquote>
<p>Ah, et cela peut sembler évident, mais : ne stockez pas la copie de sauvegarde de votre clef privée sur un support chiffré avec la clef publique correspondante, qui nécessiterait la clef privée pour y accéder !</p>
</blockquote>
<p>Une option de sauvegarde que j’apprécie particulièrement et que je recommande est celle de la sauvegarde sur papier. L’outil <a href="http://www.jabberwocky.com/software/paperkey/">Paperkey</a> est spécialement conçu pour ça : donnez‑lui votre copie de sauvegarde et il en fera une version imprimable :</p>
<pre><code>$ paperkey --secret-key backup.gpg | lpr
</code></pre>
<blockquote>
<p>Avoir des sauvegardes, c’est bien. Savoir les utiliser le jour où on en a besoin, c’est mieux. Les trois commandes suivantes restaurent successivement votre propre clef (parties publiques et privées), les clefs publiques de vos correspondants, et les informations de confiance :<br>
<code><br>
$ gpg --import backup.gpg<br>
$ gpg --import public-keys.gpg<br>
$ gpg --import-ownertrust < trust.txt<br>
</code></p>
<p>Si vous devez restaurer votre clef à partir de la sauvegarde sur papier générée par paperkey, numérisez le papier en question, passez‑le à la reconnaissance optique de caractères (OCR) pour obtenir un fichier texte (appelé <code>frompaper.txt</code> dans la commande ci‑dessous), puis utilisez paperkey à nouveau pour reconstituer le fichier <code>backup.gpg</code> :<br>
<code><br>
$ paperkey --pubring public-keys.gpg --secrets frompaper.txt --output backup.gpg<br>
</code></p>
<p>Notez l’utilisation du fichier <code>public-keys.gpg</code>, dans lequel paperkey vient trouver les parties publiques de votre clef (qui sont absentes de la version imprimable).</p>
</blockquote>
<h3 id="toc-mettre-à-labri-le-certificat-de-révocation">Mettre à l’abri le certificat de révocation</h3>
<p>Un certificat de révocation vous permet de signaler à vos correspondants de ne plus utiliser votre clef publique, dans l’éventualité où vous ne seriez plus en mesure d’utiliser la clef privée correspondante — typiquement, soit parce que vous avez perdu la clef elle‑même (je vous avais bien dit de faire une copie de sauvegarde…), soit parce que vous avez oublié la phrase de passe qui la protège.</p>
<p>De nombreux tutoriels vous enjoignent de créer un tel certificat immédiatement après avoir créé votre clef. Toutefois, c’est inutile. En effet, GnuPG l’a déjà fait pour vous, comme vous l’avez peut‑être remarqué dans les sorties console plus haut :</p>
<pre><code>gpg: revocation certificate stored as '/home/alice/.gnupg/openpgp-revocs.d/7685DC4214D727BB011BD6B754B4CC7749CAE7C3.rev'
</code></pre>
<p>Vous le trouverez donc le dossier <code>.gnupg/openpgp-revocs.d</code>, dans un fichier nommé d’après l’empreinte de votre clef.</p>
<p>C’est probablement une bonne idée de stocker ce certificat ailleurs que sur la machine où vous avez déjà votre clef, puisque vous ne voulez pas perdre ce certificat en même temps que la clef elle‑même. Attention, où que vous décidiez de le stocker, gardez à l’esprit que quiconque met la main dessus peut unilatéralement révoquer votre clef, sans avoir en sa possession la clef privée et sans la connaissance de la phrase de passe (c’est tout l’objet de ce certificat que de ne pas avoir besoin de la clef privée).</p>
<p>N’utilisez ce certificat de révocation <em>que</em> dans le cas où vous perdez l’usage de votre clef. Si vous en avez toujours l’usage et que vous souhaitez la révoquer pour une toute autre raison (par exemple, simplement parce que vous estimez qu’elle a fait son temps et que vous souhaitez la remplacer par une nouvelle, ou si vous craignez qu’elle n’ait été compromise), générez un certificat de révocation <em>ad hoc</em> au moment où vous en avez besoin :</p>
<pre><code>$ gpg -o revcert.asc --generate-revocation alice@example.org
sec rsa2048/54B4CC7749CAE7C3 2020-05-13 Alice <alice@example.org>
Faut-il créer un certificat de révocation pour cette clef ? (o/N) o
Choisissez la cause de la révocation :
0 = Aucune cause indiquée
1 = La clef a été compromise
2 = La clef a été remplacée
3 = La clef n’est plus utilisée
Q = Annuler
(Vous devriez sûrement sélectionner 1 ici)
Quelle est votre décision ? 2
Entrez une description facultative, en terminant par une ligne vide :
>
Cause de révocation : La clef a été remplacée
(Aucune description donnée)
Est-ce d’accord? (o/N) o
Sortie forcée avec armure ASCII.
Certificat de révocation créé.
Veuillez le déplacer sur un support que vous pouvez cacher ; toute personne
accédant à ce certificat peut l’utiliser pour rendre votre clef inutilisable.
Imprimer ce certificat et le stocker ailleurs est une bonne idée, au cas où le
support devienne illisible. Attention tout de même : le système d’impression
utilisé pourrait stocker ces données et les rendre accessibles à d’autres.
</code></pre>
<p>L’avantage d’un certificat de révocation <em>ad hoc</em>, par rapport à un certificat « générique » généré préventivement à la création de la clef, est double. D’une part, comme illustré dans la sortie ci‑dessus, il permet de spécifier la raison motivant la révocation ; d’autre part, dans les cas où la clef est révoquée pour une raison autre qu’une compromission (choix 2 ou 3 ci‑dessus : clef remplacée ou plus utilisée), les signatures émises par la clef antérieurement à la révocation resteront valables, alors que dans le cas d’une clef révoquée sans raison explicitement spécifiée, <em>toutes</em> les signatures jamais émises par la clef sont remises en cause (comme dans le cas où la clef a été compromise).</p>
<p>Pour utiliser un certificat de révocation, importez‑le simplement dans votre trousseau avec <code>gpg --import</code>. Attention, importer un certificat de révocation ne demande pas de confirmation et est irréversible.</p>
<h2 id="toc-diffuser-la-clef-publique">Diffuser la clef publique</h2>
<p>Maintenant que vous avez une clef, il vous faut mettre la partie publique à disposition de vos correspondants.</p>
<h3 id="toc-les-serveurs-de-clefs-sks">Les serveurs de clefs SKS</h3>
<p>Pendant longtemps, la méthode « classique » pour diffuser une clef publique a consisté à l’envoyer sur un des serveurs de clefs disponibles un peu partout sur Internet. Ces serveurs font typiquement partie d’un réseau au sein duquel les différentes instances se synchronisent régulièrement. Non seulement cela permet à l’utilisateur de ne pas se soucier du serveur auquel il s’adresse, mais cela fournit aussi une certaine résilience, aussi bien face aux incidents (un des serveurs du réseau devient subitement inaccessible) que contre certaines interférences de gens malintentionnés.</p>
<p>Malheureusement, aujourd’hui la survie à long terme du réseau des serveurs de clefs est incertaine. Il y a plusieurs raisons à cela, qui sortent du cadre de cet article, mais on peut citer pêle‑mêle : quasiment pas de développeurs motivés pour travailler sur le logiciel serveur de référence (<a href="https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Home">SKS-Keyserver</a>), un réseau entièrement dépendant de la bonne volonté des administrateurs (tous les nœuds sont gérés bénévolement), des désaccords dans la communauté sur les fonctionnalités que doit ou ne doit pas offrir un serveur de clefs, un principe de fonctionnement qui rend les serveurs vulnérables aux empoisonnements… C’est notamment ce dernier point qui, en 2019, a porté un coup probablement fatal au réseau, avec une attaque par empoisonnement visant quelques membres influents de la communauté.<sup id="fnref2"><a href="#fn2">2</a></sup></p>
<p>Quelles que soient les raisons, le fait est qu’il n’y a plus, à l’heure où j’écris ces lignes, qu’à peine une vingtaine de serveurs dans le groupe principal <em><a href="https://sks-keyservers.net/status/">sks-keyservers.net</a></em>, contre facilement plus d’une centaine habituellement. Le réseau est toujours utilisable <em>pour l’instant</em>, mais il faut se préparer à ne plus pouvoir compter dessus dans un futur plus ou moins proche.</p>
<p>Pour l’instant donc, GnuPG est toujours configuré pour utiliser le groupe <em>sks-keyservers.net</em> par défaut, alors tant que le pool est vivant et si vous acceptez une certaine incertitude sur la disponibilité, vous n’avez rien de particulier à faire. Pour envoyer votre clef dont l’identifiant est <code>7685DC4214D727BB011BD6B754B4CC7749CAE7C3</code> sur un des serveurs du réseau, faites simplement :</p>
<pre><code>$ gpg --send-keys 7685DC4214D727BB011BD6B754B4CC7749CAE7C3
</code></pre>
<p>ou avec les huit derniers octets :</p>
<pre><code>$ gpg --send-keys 54B4CC7749CAE7C3
</code></pre>
<p>voire seulement les quatre derniers octets :</p>
<pre><code>$ gpg --send-keys 49CAE7C3
</code></pre>
<h3 id="toc-le-serveur-keysopenpgporg">Le serveur keys.openpgp.org</h3>
<p>Un nouveau serveur de clefs a récemment vu le jour, en partie en réaction aux déboires du réseau SKS : <em><a href="https://keys.openpgp.org/">keys.openpgp.org</a></em>. Il utilise non pas SKS-Keyserver, mais <a href="https://gitlab.com/hagrid-keyserver/hagrid">Hagrid</a> (le « gardien des clefs » de Poudlard), un serveur de clefs basé sur Sequoia-PGP (une bibliothèque OpenPGP en Rust).</p>
<p>Bien qu’il puisse être considéré comme un remplaçant ou un successeur du réseau SKS, plusieurs différences importantes sont à noter avant de décider de l’utiliser.</p>
<p>Il s’agit d’<em>un</em> serveur, non d’un groupe (<em>pool</em>). Même si n’importe qui peut monter son propre serveur Hagrid (tout comme avec SKS), il n’y a aucune synchronisation possible entre serveurs (contrairement à SKS, pour lequel c’est même une fonctionnalité majeure). Même si les développeurs affirment qu’une certaine décentralisation est prévue à l’avenir, ils préviennent que, quelle que soit la forme que prendra cette décentralisation, il ne sera pas question d’une « fédération ouverte » similaire à SKS (ce qui personnellement me fait m’interroger sur ce que peut être une fédération « fermée » — d’autant que contrairement à ce qu’ils semblent suggérer, n’entrait déjà pas dans le groupe SKS qui veut). Le serveur <em>keys.openpgp.org</em> est donc un <a href="_single%20point%20of%20failure_">point de défaillance unique</a> et un point d’attaque unique (<em>single point of attack</em>).</p>
<p>Hagrid vérifie les adresses de courriel lorsqu’une clef est déposée sur le serveur, afin que seul le titulaire d’une adresse ne puisse déposer une clef associée à cette adresse. Le but étant à la fois de permettre à chacun de garder le contrôle sur ce qui est publié par le serveur, et d’offrir la garantie qu’une clef trouvée sur le serveur appartient bien à qui elle déclare appartenir (deux garanties jamais offertes par les serveurs classiques, par conception). C’est sympathique, mais cela implique que le serveur est de fait analogue à une autorité de certification à laquelle vous devez faire confiance, une idée qui personnellement ne me plaît guère.<sup id="fnref3"><a href="#fn3">3</a></sup></p>
<p>Dernier point, et pas des moindres, Hagrid viole délibérément le standard OpenPGP dans certaines situations (notamment pour la diffusion des certificats de révocation), en diffusant des paquets de clef publique associés à aucune identité — ce que le standard ne permet pas. Cela conduit les implémentations conformes à refuser certains paquets en provenance d’un serveur Hagrid. Ce n’est pas un « bogue de GnuPG » comme le laisse entendre la FAQ de <em>keys.openpgp.org</em>.</p>
<p>Cela étant dit, si vous souhaitez utiliser ce serveur pour y chercher des clefs, il vous suffit d’ajouter la ligne suivante dans le fichier <code>~/.gnupg/dirmngr.conf</code> :</p>
<pre><code>keyserver hkps://keys.openpgp.org
</code></pre>
<p>Puis relancer le démon réseau de GnuPG, <em>dirmngr</em> :</p>
<pre><code>$ gpgconf --reload dirmngr
</code></pre>
<p>Pour <em>déposer</em> une clef, en revanche, la commande <code>--send-keys</code> de GnuPG ne suffit pas, puisqu’elle ne permet pas à Hagrid de vérifier l’adresse (ce n’est pas prévu par le protocole HKP, utilisé par GnuPG derrière cette commande). À la place, il vous faut exporter la clef :</p>
<pre><code>$ gpg -o alice.pub --export alice@example.org
</code></pre>
<p>Puis télécharger le fichier <code>alice.pub</code> sur <em><a href="https://keys.openpgp.org/upload">keys.openpgp.org/upload</a></em>, et suivre les instructions d’Hagrid pour procéder à la vérification d’adresse.</p>
<blockquote>
<p>Si vous utilisez le greffon Enigmail pour Thunderbird, il utilise déjà <em>keys.openpgp.org</em> par défaut et implémente l’API spécifique de Hagrid (en remplacement du protocole HKP), lui permettant de procéder à la vérification d’adresse en arrière‑plan sans intervention de l’utilisateur.</p>
</blockquote>
<h3 id="toc-autres-méthodes-de-distribution">Autres méthodes de distribution</h3>
<p>D’autres méthodes existent pour assurer la diffusion des clefs publiques, notamment la publication dans le DNS (DANE, <a href="https://tools.ietf.org/html/rfc7929">RFC 7929</a>) et dans un <em>Web Key Directory</em> (<a href="https://www.ietf.org/id/draft-koch-openpgp-webkey-service-10.txt">WKD</a>). Pour ces deux méthodes je vous renvoie à un <a href="//linuxfr.org/users/gouttegd/journaux/de-la-distribution-des-clefs-openpgp">précédent journal</a> ; néanmoins la mise en œuvre de DANE et de WKD dépend de celui qui contrôle le domaine de votre adresse de courriel (votre fournisseur d’accès à Internet ou de messagerie, votre employeur, votre université…) — à moins que vous ne disposiez de votre propre domaine, décider d’utiliser DANE ou WKD n’est pas vraiment de votre ressort.</p>
<p>Au‑delà des méthodes formalisées de distribution (serveurs de clefs décentralisés ou non, DANE, WKD), vous pouvez (devez ?) aussi distribuer votre clef par tous les moyens possibles et imaginables. La poster sur un forum, sur votre blog, dans votre profil Facebook (il y a un champ dédié à cet usage), etc.</p>
<p>Là où il n’est pas pratique de publier la clef proprement dite faute de place, n’hésitez pas à publier <em>a minima</em> son empreinte : sur votre profil Twitter ou Mastodon (ou n’importe quel autre type de réseau dit « social »), sur vos cartes de visite, en signature de vos messages sur les forums où vous intervenez, etc.</p>
<p>Pour obtenir l’empreinte d’une clef (dont la vôtre), demandez simplement à GnuPG d’afficher ladite clef :</p>
<pre><code>$ gpg -k alice@incenp.org
pub rsa2048 2020-05-13 [SC]
7685DC4214D727BB011BD6B754B4CC7749CAE7C3
uid [ ultime ] Alice <alice@example.org>
sub rsa2048 2020-05-13 [E]
</code></pre>
<h2 id="toc-chiffrer-signer-des-fichiers">Chiffrer, signer des fichiers</h2>
<p>Cette section passe rapidement en revue la manière d’utiliser GnuPG sur des fichiers locaux, sans communication avec l’extérieur.</p>
<h3 id="toc-chiffrer-un-fichier">Chiffrer un fichier</h3>
<p>Pour chiffrer un fichier à votre propre attention, la commande de base est la suivante :</p>
<pre><code>$ gpg -r alice@example.org -e lorem.txt
</code></pre>
<p>L’option <code>-r UID</code> (ou <code>--recipient UID</code>) indique la clef publique avec laquelle chiffrer le fichier. Elle attend en paramètre l’identité (UID, <em>User ID</em>) associée à la clef que vous voulez utiliser. Ici, il s’agit de la vôtre (en supposant, comme dans tout le reste de ce journal, que vous êtes Alice). Notez que vous n’avez pas nécessairement besoin de spécifier l’identité en entier, dès lors qu’il n’y a aucune ambiguïté : si votre trousseau de clefs publiques ne contient qu’une seule clef dont l’identité associée contient la chaîne « alice », alors <code>-r alice</code> sera suffisant (dans le cas contraire, si plusieurs clefs peuvent correspondre, GnuPG sélectionnera arbitrairement la première qu’il trouve dans le trousseau, qui ne sera peut‑être pas celle que vous vouliez).</p>
<p>Si vous prévoyez de chiffrer des fichiers à votre attention assez fréquemment, vous pouvez envisager d’ajouter l’option <code>default-recipient-self</code> dans le fichier de configuration de GnuPG (<code>~/.gnupg/gpg.conf</code>) ; elle conduira GnuPG à sélectionner votre propre clef publique par défaut si vous ne spécifiez aucune clef explicitement. Avec cette option en place, la commande ci‑dessus devient simplement :</p>
<pre><code>$ gpg -e lorem.txt
</code></pre>
<p>Le paramètre <code>-e</code> (ou <code>--encrypt</code>) est la commande de chiffrement. Elle attend simplement le nom du fichier à chiffrer, dans le cas présent <code>lorem.txt</code>. Cette commande produira un fichier <code>lorem.txt.gpg</code> contenant la version chiffrée du fichier précédent.</p>
<blockquote>
<p>Quelle que soit l’opération que vous demandez à GnuPG (chiffrer, signer, déchiffrer), vous pouvez toujours utiliser l’option <code>-o</code> (ou <code>--output</code>) pour spécifier explicitement le nom du fichier de sortie.</p>
</blockquote>
<h3 id="toc-signer-un-fichier">Signer un fichier</h3>
<p>Il y a trois commandes différentes pour effectuer une signature, qui correspondent aux trois types de signature possibles :</p>
<ul>
<li>la signature « standard » (faute d’un meilleur nom pour la désigner), demandée avec la commande <code>-s</code> (ou <code>--sign</code>), qui produit un fichier contenant à la fois le document qui a été signé (enveloppé dans un paquet OpenPGP) <em>et</em> la signature correspondante ;</li>
<li>la signature en clair (<em>cleartext signature</em>), avec la commande <code>--clear-sign</code>, qui produit aussi un fichier contenant à la fois le document original et sa signature, mais ici le document original n’est pas enveloppé dans un paquet OpenPGP et reste sous une forme textuelle lisible — ce type de signature n’est utile que si le document original à signer est lui‑même de type texte, une signature en clair sur un document binaire n’a aucun sens ;</li>
<li>la signature détachée, avec la commande <code>-b</code> (ou <code>--detach-sign</code>), qui produit un fichier ne contenant <em>que</em> la signature, sans le document original ; lors de la vérification, le document original doit être fourni à GnuPG en même temps que la signature détachée — ce type de signature est typiquement utilisé pour signer les archives de code source, l’avantage dans ce cas de figure étant que ceux qui ne sont pas intéressés par la vérification de la signature peuvent utiliser l’archive directement, sans avoir à l’extraire de son enveloppe OpenPGP, comme dans le cas d’une signature « normale ».</li>
</ul>
<p>Il est possible de signer <em>et</em> chiffrer en même temps en combinant les commandes <code>-s</code> et <code>-e</code>. Dans ce cas, le fichier produit contient à la fois le document chiffré et la signature correspondante. Ce n’est possible que pour les signatures « standard », combiner chiffrement et signature en clair ou détachée n’a pas de sens.</p>
<p>Toutes les commandes de signature utilisent par défaut la première clef trouvée dans le trousseau de clefs secrètes. La plupart des utilisateurs n’ont normalement qu’une seule clef secrète (compte non tenu des sous‑clefs), donc ce comportement convient la plupart du temps. Si néanmoins vous avez plusieurs clefs secrètes, vous pouvez ajouter l’option <code>default-key UID1</code> dans le fichier de configuration de GnuPG pour toujours signer avec la clef associée à l’identité <em>UID1</em>, ou utiliser l’option <code>-u UID2</code> sur la ligne de commande pour ponctuellement signer avec la clef associée à l’identité <em>UID2</em>.</p>
<p>Les commandes de signatures produisent par défaut un fichier portant le même nom que le fichier à signer plus une extension dépendant du type de signature :<code>.gpg</code> pour une signature normale, <code>.asc</code> pour une signature en clair, <code>.sig</code> pour une signature détachée. Ces extensions sont purement conventionnelles et n’ont aucune signification pour GnuPG, qui identifie les fichiers qu’il manipule sur la base du type de paquets OpenPGP qu’ils contiennent et non sur leur extension.</p>
<h3 id="toc-déchiffrer-vérifier-un-fichier">Déchiffrer, vérifier un fichier</h3>
<p>La commande <code>-d</code> (ou <code>--decrypt</code>) déchiffre un fichier :</p>
<pre><code>$ gpg -d lorem.txt.gpg
gpg: chiffré avec une clef RSA de 2048 bits, identifiant 45EDD81BCE62E9BD, créée le 2020-05-13
"Alice <alice@example.org>
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Ut purus
[...]
</code></pre>
<p>Notez l’asymétrie entre les commandes de chiffrement (<code>-e</code>) et de déchiffrement (<code>-d</code>) : la première produit un fichier, tandis que la seconde écrit par défaut sur la sortie standard.</p>
<p>Si le fichier <code>lorem.txt.gpg</code> est un fichier chiffré et signé, GnuPG vérifiera la signature en même temps qu’il déchiffrera, et affichera le résultat à la fin de l’opération :</p>
<pre><code>$ gpg -d lorem.txt.gpg
gpg: chiffré avec une clef RSA de 2048 bits, identifiant 45EDD81BCE62E9BD, créée le 2020-05-13
"Alice <alice@example.org>
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Ut purus
[…]
gpg: Signature faite le mar. 19 mai 2020 23:23:21 BST
gpg: avec la clef RSA 7685DC4214D727BB011BD6B754B4CC7749CAE7C3
gpg: Bonne signature de « Alice <alice@example.org> » [ultime]
</code></pre>
<p>La commande <code>-d</code>, malgré son nom, s’utilise aussi sur un fichier signé uniquement, pour vérifier la signature et extraire le document signé de son enveloppe OpenPGP et le rendre ainsi utilisable.</p>
<p>On utilisera la commande <code>--verify</code> pour vérifier une signature en clair…</p>
<pre><code>$ gpg --verify lorem.txt.asc
gpg: Signature faite le mar. 19 mai 2020 23:34:22 BST
gpg: avec la clef RSA 7685DC4214D727BB011BD6B754B4CC7749CAE7C3
gpg: Bonne signature de « Alice <alice@example.org> » [ultime]
</code></pre>
<p>… ainsi que pour vérifier une signature détachée. Dans ce cas, GnuPG attend en premier argument le fichier de signature proprement dit, et en second argument le document original (en l’absence de cet argument, GnuPG cherchera un fichier portant le même nom que le fichier de signature moins l’extension <code>.sig</code>, mais il est préférable de spécifier le fichier explicitement) :</p>
<pre><code>$ gpg --verify lorem.txt.siglorem.txt
gpg: Signature faite le mar. 19 mai 2020 23:41:52 BST
gpg: avec la clef RSA 7685DC4214D727BB011BD6B754B4CC7749CAE7C3
gpg: Bonne signature de « Alice <alice@example.org> » [ultime]
</code></pre>
<p>Il est aussi possible d’utiliser la commande <code>--verify</code> sur une signature « standard » ; mais dans ce cas, GnuPG ne fera <em>que</em> vérifier la signature, sans extraire le document signé, contrairement à ce que fait la commande <code>-d</code>.</p>
<p><img src="//img.linuxfr.org/img/68747470733a2f2f696e63656e702e6f72672f66696c65732f6d6973632f323032302f6770612d66696c656f70732e706e67/gpa-fileops.png" alt="Fig. 2" title="Source : https://incenp.org/files/misc/2020/gpa-fileops.png"> <em><strong>Figure 2</strong> — Exemples d’opérations sur des fichiers avec GPA. Pour chiffrer un fichier, ouvrez‑le dans le</em> File Manager <em><strong>(A)</strong> et cliquez sur le bouton correspondant dans la barre d’outils. Dans la fenêtre de dialogue qui s’ouvre <strong>(B)</strong>, sélectionnez la clef publique avec laquelle chiffrer le document, et éventuellement la clef privée avec laquelle le signer. En <strong>(C)</strong>, un exemple du résultat d’une vérification de signature.</em></p>
<h2 id="toc-chiffrer-signer-des-courriels">Chiffrer, signer des courriels</h2>
<p>Pour finir, il est temps d’utiliser GnuPG pour ce pour quoi il est en principe conçu (même si en vrai vous l’utilisez bien pour ce que vous voulez…), à savoir chiffrer et signer des courriels.</p>
<p>Si vous n’avez pas d’amis, vous pouvez toujours envoyer un courriel à <em>Edward</em>, un automate (<em>bot</em>) mis en place par la Free Software Foundation pour permettre aux gens d’essayer le chiffrement des courriels.</p>
<h3 id="toc-obtenir-la-clef-dedward">Obtenir la clef d’Edward</h3>
<p>La première étape pour établir une communication chiffrée, que ce soit avec Edward ou n’importe qui d’autre, est d’obtenir la clef publique de votre correspondant.</p>
<p>Cherchez donc la clef d’Edward sur les serveurs de clefs, et importez‑la :</p>
<pre><code>$ gpg --search-keys edward-fr@fsf.org
gpg: data source: http://pgp.surf.nl:11371
(1) Edward, el simpático robot GnuPG <edawrd-es@fsf.org>
Edward the GPG Bot <edward@fsf.org>
Edward, the GPG Bot <edward-en@fsf.org>
Edward, le gentil robot de GnuPG <edward-fr@fsf.org>
[…]
2048 bit RSA key 9FF2194CC09A61E8, créé : 2014-06-29
Keys 1-1 of 1 for "edward-fr@fsf.org". Entre le ou les nombres, (S)uivant, ou (Q)uitter > 1
gpg: clef 9FF2194CC09A61E8 : clef publique « Edward, el simpático robot GnuPG <edward-es@fsf.org> » importée
gpg: Quantité totale traitée : 1
gpg: importées : 1
</code></pre>
<p>Si vous avez choisi, dans la section relative aux serveurs de clefs, d’utiliser le nouveau serveur <em>keys.openpgp.org</em>, la clef d’Edward n’y est malheureusement pas disponible. Dans ce cas, vous pouvez utiliser l’option <code>--keyserver</code> sur la ligne de commande pour ponctuellement ignorer le serveur que vous avez configuré dans <code>~/.gnupg/dirmngr.conf</code> :</p>
<pre><code>$ gpg --keyserver hkp://pool.sks-keyservers.net --search-keys edward-fr@fsf.org
</code></pre>
<p>En cas de problème avec le réseau SKS, une copie de la clef est incluse ci‑dessous :</p>
<pre><code>-----BEGIN PGP PUBLIC KEY BLOCK-----
mQENBFOwfzoBCADpwK6sGC3EUzgD7IW1X5ZDR1nC5/rcXacAJLarPpvQBEz4pwjT
joAzATM7F9RwIzJ3hJTZHiYaQY4cfiGlKSnrd8GPC8A4QkxXIaQ0hLpcsBSbtZJp
o2iOzL2fRHmW2ZlnSHXPKbDwx5p0NcdQfjL9i2Yo31aLIO/Chhn5uyvIznOjaCSC
/O6x2C4m81Lu+B4UTDpl8y6ChtphUxyFGd7RXDXmkYQrxVqJbXKuSVmNMhM09myG
7iQ1l0YLOcCxa3IXDqQkte49BhMGB9wl4eDTE86HEzRjMtdhFpbTOW/+1N4XkOUV
y42HzGtmSAttojpIp00foNlWn1sn7JZJ18ojABEBAAG0NEVkd2FyZCwgbGUgZ2Vu
dGlsIHJvYm90IGRlIEdudVBHIDxlZHdhcmQtZnJAZnNmLm9yZz6JATgEEwECACIF
AlOxd9YCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEJ/yGUzAmmHorAwI
AI/THdk1Lj0IoYxGzOxGq1j2l1iRa2JcKNdsj0PzSpDHjtycCqJZrjBWAMJRymBt
WHeS6KLw992cEbmZ7wh0ObFXSicDTBOTAu3xwjNIRATAlH3f5nPNMnyULiNUbQin
naU7zOr/Iq88onb3FrjqhGETdxGXBm6RgoWGX7vdzdgY99CnC5bTt3TCu+9ddzVJ
NxS3yycwPl4IlRaSyQHQIMMRVs3p0e/8cqtZDBzsMOLPtoRGFoYBo3/pZWwF7kFX
n6u/z7UzuvW+COYtU2wIdSVkdmpn9jWl4+7UgKOXprDcQmrdGiCeErUxPbpWikza
VvVQkruAG9skMjuSk0Cmmai5AQ0EU7B/OgEIAMJfFthcYpgykvEHCBVm6vpMof1E
xuQ1bxNI1KVs2GTXF2sn9dXa6RvM6dz9xferglaZnsG+j7ACVaEHsgqe/E0VjhIS
NP1sJgH4dtyoL06dWp6Bs8SdI1Jasm+h55cXgYagahNpub1TUxjpsu8ZsyM/5cRp
B2HCmCXIsTYPEwIQu77XMpNo+mRi8oguOJ44ZMIYrvzivrJh1GnCbimSFfj7eMoF
1SHwl+e+k8reDqnoIWp514NGo9LLlwGIG0TQcg9S/tIchibmMZOV+xSS+MFxpMvm
eWCrgVJdK2paJ4d+8ZaxvkRDEtfGbmTOr7dFfA8i1heIPcbw4ejZEHGKWesAEQEA
AYkBHwQYAQIACQUCU7B/OgIbDAAKCRCf8hlMwJph6O+7CADBAYe5gTjFsA+vwVNt
gwrYXQv/w1XIndFUsOO3T7NjfTVETd652kIU4zFJRf3ebXbxz3E+1f1qPuVD8WJ9
5Roeyl8nsEoxr+iB6+/FqRIbHMnC0qqYRjVYvtD5ezgNpqGy/3dJmrhOuj7JHKIm
aB6tALq6JWb5URDHU5tCHPCyBJQhuMGBZzzyAexmBSk2CiKLX9DyX36ZO2+vlQK4
X0FW1M4qrC1gEB7sEpP9xTsST7MZr9USevwRcbRd/GvPFpTnI6JWazAmnhoRyOEA
ld6ORPNW1EUPBsIhfazP3v5SG5NXDAjYMHH/MbX872FhoBWerfHpi1yyZPHSkkXI
UAaY
=/0NJ
-----END PGP PUBLIC KEY BLOCK-----
</code></pre>
<p>Copiez‑la dans un fichier, puis importez‑la manuellement :</p>
<pre><code>$ gpg --import edward.asc
</code></pre>
<p>Une fois la clef d’Edward dans votre trousseau public, il faut la signer pour la marquer comme valide (je vous renvoie à un <a href="//linuxfr.org/users/gouttegd/journaux/de-la-confiance-dans-le-monde-openpgp">précédent journal</a> pour plus de détails sur la notion de validité, et notamment pour savoir en quoi le fait de signer une clef la rend valide). Pour cela, lancez l’éditeur de clefs sur la clef d’Edward :</p>
<pre><code>$ gpg --edit-key edward-fr@fsf.org
pub rsa2048/9FF2194CC09A61E8
créé : 2014-06-29 expire : jamais utilisation : SC
confiance : inconnu validité : inconnu
sub rsa2048/469DDF6D9014D2D6
créé : 2014-06-29 expire : jamais utilisation : E
[ inconnue] (1). Edward, el simpático robot GnuPG <edward-es@fsf.org>
[ inconnue] (2) Edward the GPG Bot <edward@fsf.org>
[ inconnue] (3) Edward, the GPG Bot <edward-en@fsf.org>
[ inconnue] (4) Edward, le gentil robot de GnuPG <edward-fr@fsf.org>
[…]
</code></pre>
<p>Affichez l’empreinte complète de la clef et vérifiez qu’elle correspond à l’empreinte dans la sortie ci‑dessous :</p>
<pre><code>gpg> fpr
pub rsa2048/469DDF6D9014D2D6 2014-06-29 Edward, el simpático robotGnuPG <edward-es@fsf.org>
Empreinte clef princip. : F357 AA1A 5B1F A42C FD9F E52A 9FF2 194C C09A 61E8
</code></pre>
<p>Si l’empreinte correspond, vous pouvez procéder à la signature :</p>
<pre><code>gpg> sign
Voulez-vous vraiment signer toutes les identités ? (o/N) o
pub rsa2048/9FF2194CC09A61E8
créé : 2014-06-29 expire : jamais utilisation : SC
confiance : inconnu validité : inconnu
Empreinte clef princip. : F357 AA1A 5B1F A42C FD9F E52A 9FF2 194C C09A 61E8
Edward, el simpático robot GnuPG <edwardes@fsf.org>
Edward the GPG Bot <edward@fsf.org>
Edward, the GPG Bot <edward-en@fsf.org>
Edward, le gentil robot de GnuPG <edward-fr@fsf.org>
[…]
Voulez-vous vraiment signer cette clef avec votre
clef « Alice <alice@example.org> » (54B4CC7749CAE7C3)
Voulez-vous vraiment signer ? (o/N) o
gpg> save
</code></pre>
<h3 id="toc-thunderbird-et-enigmail">Thunderbird et Enigmail</h3>
<p>Si vous utilisez le client de messagerie électronique <a href="https://www.thunderbird.net/">Thunderbird</a>, vous devez (pour l’instant) installer le greffon <a href="https://enigmail.net/">Enigmail</a> pour y ajouter la prise en charge d’OpenPGP, Thunderbird ne gérant nativement que S/MIME. Cherchez Enigmail depuis le gestionnaire de greffons de Thunderbird, puis installez‑le.</p>
<blockquote>
<p>Enigmail ne fonctionnera plus à partir de Thunderbird 78, dont la sortie est prévue d’ici la fin de l’année 2020. À la place, la nouvelle version de Thunderbird <a href="https://blog.thunderbird.net/2019/10/thunderbird-enigmail-and-openpgp/">prendra nativement en charge OpenPGP</a> sans qu’un greffon ne soit nécessaire.</p>
<p>L’étendue de cette prise en charge native reste encore à voir, mais elle sera probablement, au moins dans l’immédiat, <a href="https://wiki.mozilla.org/Thunderbird:OpenPGP:2020">plus limitée</a> que ce qui est actuellement offert par Enigmail.</p>
<p>Une chose semble déjà sûre, Thunderbird n’utilisera pas les trousseaux de GnuPG (pas plus le trousseau public que le trousseau privé). Il sera possible d’importer les clefs de GnuPG vers Thunderbird, mais une fois cela fait, les clefs importées seront gérées par Thunderbird indépendamment de GnuPG — toute modification faite dans GnuPG sera invisible depuis Thunderbird et inversement.</p>
<p>À titre personnel, je trouve que c’est une très mauvaise idée. Et je suis globalement assez dubitatif de l’approche consistant à jeter à la poubelle une implémentation pleinement fonctionnelle pour après coup se rendre que compte que « oh, ben zut, il y avait des fonctionnalités utiles en fait ; bon, comment on fait pour les réimplémenter <em>from scratch</em> maintenant ? », comme avec la <a href="https://mail.mozilla.org/pipermail/tb-planning/2019-December/007288.html">gestion des cartes OpenPGP</a>.</p>
<p>L’avenir dira si cette orientation aura permis d’attirer de nouveaux utilisateurs ou si elle aura surtout fait fuir les utilisateurs déjà existants. /rant</p>
</blockquote>
<p><img src="//img.linuxfr.org/img/68747470733a2f2f696e63656e702e6f72672f66696c65732f6d6973632f323032302f656e69676d61696c2e706e67/enigmail.png" alt="Fig3" title="Source : https://incenp.org/files/misc/2020/enigmail.png"> <em><strong>Figure 3</strong> — Utilisation d’Enigmail dans Thunderbird. <strong>(A)</strong> Sitôt installé, Enigmail détecte votre installation de GnuPG et vos clefs pré‑existantes. <strong>(B)</strong> Envoi d’un courriel chiffré et signé à Edward, auquel on joint une copie de sa propre clef publique. <strong>(C)</strong> Réception et déchiffrement de la réponse automatique d’Edward.</em></p>
<p>Une fois Enigmail installé, il devrait automatiquement détecter GnuPG et vous proposer de se configurer pour utiliser la clef que vous avez déjà ; acceptez en cliquant sur <em>Apply my keys</em> (figure 3A).</p>
<blockquote>
<p>Si vous installez Enigmail sans avoir préalablement généré vous‑même votre clef, Enigmail en générera silencieusement une pour vous, mais se configurera automatiquement pour utiliser <em>p≡p</em> plutôt que GnuPG. Sans rentrer dans les détails, <a href="https://www.pep.security/">p≡p</a> est une solution de chiffrement opportuniste, basée entre autres sur OpenPGP mais où, en gros, l’utilisateur ne contrôle plus rien… L’utilisation de p≡p a parfois été appelée <em>Junior mode</em>, mais ce terme ne semble plus apparaître dans la documentation ou l’interface d’Enigmail.</p>
</blockquote>
<p>Vous pouvez maintenant envoyer un courriel à <code>edward-fr@fsf.org</code> (figure 3B). Par défaut, le message sera signé, et comme la clef publique d’Edward est déjà dans votre trousseau, Enigmail devrait reconnaître son adresse et aussi activer le chiffrement. Si vous voulez qu’Edward puisse chiffrer également sa réponse à votre attention, pensez à joindre votre propre clef publique au message, en utilisant l’option appropriée dans le menu d’Enigmail.</p>
<blockquote>
<p>Lors de l’envoi, il se peut qu’Enigmail vous propose une option appelée <em>protected headers</em>, qui vise à chiffrer certains en‑têtes du message (notamment l’objet) et non seulement le corps du message. Je déconseille personnellement cette option qui repose sur une <a href="https://www.ietf.org/id/draft-autocrypt-lamps-protected-headers-02.txt">proposition de standard</a> à mon sens beaucoup trop complexe pour le bénéfice qu’elle apporte, et dont la prise en charge par un grand nombre de clients de messagerie est incertain. Gardez plutôt à l’esprit que les en‑têtes ne sont <em>pas</em> chiffrés,<sup id="fnref4"><a href="#fn4">4</a></sup> et abstenez‑vous de divulguer trop d’informations dans les objets de vos messages.</p>
</blockquote>
<p>Après quelques minutes, vous devriez recevoir une réponse automatique d’Edward. Vous aurez ainsi confirmation que tout s’est bien passé (figure 3C). Félicitations, vous venez de procéder à votre premier échange de courriels chiffrés.</p>
<h3 id="toc-neomutt">(Neo)Mutt</h3>
<p>Si vous utilisez le client <a href="http://mutt.org/">Mutt</a> ou la divergence (<em>fork</em>) <a href="https://neomutt.org/">Neomutt</a>, tous deux prennent nativement en charge OpenPGP et ne nécessitent qu’un minimum de configuration. Ajoutez simplement les deux lignes suivantes à votre fichier <code>mutrc</code> :</p>
<pre><code>set crypt_use_gpgme = yes
set pgp_default_key = 0x7685DC4214D727BB011BD6B754B4CC7749CAE7C3
</code></pre>
<p>La première ligne configure (Neo)Mutt pour utiliser la bibliothèque GpgME pour interagir avec GnuPG (ce qui est la manière recommandée par les développeurs de GnuPG), au lieu d’appeler le binaire <code>gpg</code> directement (ce qui est toujours possible mais « <em>error‑prone</em> »). La seconde ligne indique la clef à utiliser par défaut ; cette clef sera utilisée pour signer vos messages, et pour en chiffrer une copie à votre attention (afin que vous puissiez toujours déchiffrer les messages envoyés à des tiers). Remplacez la valeur indiquée par l’empreinte de votre propre clef.</p>
<p><img src="//img.linuxfr.org/img/68747470733a2f2f696e63656e702e6f72672f66696c65732f6d6973632f323032302f6e656f6d7574742e706e67/neomutt.png" alt="Fig4" title="Source : https://incenp.org/files/misc/2020/neomutt.png"> <em><strong>Figure 4</strong> — Utilisation de Neomutt. <strong>(A)</strong> Préparation d’un message chiffré et signé dans Neomutt. <strong>(B)</strong> Le menu PGP permettant de sélectionner si un message doit être chiffré, signé, signé avec une clef autre que celle configurée par défaut, chiffré <strong>et</strong> signé. <strong>(C)</strong> Le menu de sélection de la clef publique du destinataire.</em></p>
<p>Une fois (Neo)Mutt configuré, envoyez donc un courriel à Edward. Préparez le message de la manière habituelle jusqu’à arriver à la fenêtre d’envoi (figure 4A). Par défaut, le message sera seulement signé, appuyez sur la touche <code>p</code> pour appeler le menu PGP (figure 4B), puis sur la touche <code>b</code>, comme indiqué, pour demander que le message soit chiffré et signé.</p>
<p>Attachez au message une copie de votre clef publique en tapant <code>Échap</code> puis <code>k</code> et en sélectionnant votre clef dans le menu correspondant. Au moment d’envoyer le message, vous serez invité à sélectionner la clef publique avec laquelle chiffrer le message (figure 4C), parmi les clefs associées à une adresse correspondant à celle du destinataire du message. Sélectionnez la clef d’Edward (qui logiquement devrait être la seule, vous ne devriez pas avoir plus d’une clef associée à l’adresse <code>edward-fr@fsf.org</code>), puis envoyez.</p>
<p>Attendez quelques minutes de recevoir la réponse d’Edward, et vérifiez que tout s’est bien passé.</p>
<h3 id="toc-autres-clients">Autres clients</h3>
<p>Il ne serait pas réaliste de vouloir couvrir tous les clients de messagerie existants et je n’essayerai même pas.</p>
<p>Beaucoup de clients libres ont une gestion native d’OpenPGP : GNOME Evolution, KMail, Claws-Mail… En général, ils n’opposent pas de difficultés majeures.</p>
<p>Sous Windows, la distribution Gpg4Win, déjà mentionnée dans la première section, est fournie avec <em>GpgOL</em>, un greffon pour Microsoft Outlook.</p>
<p>Sous macOS, GPG Suite fournit un greffon pour Apple Mail appelé <em>GPG Mail</em>. Attention, ce greffon est libre (comme le reste de GPG Suite) mais, depuis peu, payant.</p>
<p>Sous Android, <a href="https://www.openkeychain.org/">OpenKeychain</a> apporte la prise en charge d’OpenPGP à plusieurs applications, dont le client de messagerie <a href="https://k9mail.github.io/">K‑9 Mail</a>.</p>
<blockquote>
<p>À titre personnel, il est hors de question que j’accepte de stocker une quelconque clef privée sur un téléphone Android. Je ne recommande l’utilisation d’OpenKeychain que couplée à un jeton cryptographique comme la <a href="https://www.yubico.com/product/yubikey-5-nfc">Yubibey 5 NFC</a>.</p>
</blockquote>
<h2 id="toc-comment-changer-la-date-dexpiration-de-saclef">Comment changer la date d’expiration de sa clef ?</h2>
<p><em>N. D. M. : tiré de <a href="//linuxfr.org/users/gouttegd/journaux/bien-demarrer-avec-gnupg#comment-1811720">ce fil de commentaires</a>.</em></p>
<p>La clef générée a donc une validité de deux ans. Que faire en 2022 pour pouvoir encore utiliser sa clef ?</p>
<p>Il suffit de changer la date d’expiration, ce qui se fait avec la commande <code>expire</code> dans l’éditeur de clefs de GnuPG :</p>
<pre><code class="sh">$ gpg --edit-key alice
La clef secrète est disponible.
sec rsa2048/54B4CC7749CAE7C3
créé : <span class="m">2020</span>-05-13 expire : <span class="m">2022</span>-05-13 utilisation : SC
confiance : ultime validité : ultime
ssb rsa2048/45EDD81BCE62E9BD
créé : <span class="m">2020</span>-05-13 expire : <span class="m">2022</span>-05-13 utilisation : E
<span class="o">[</span> ultime <span class="o">]</span> <span class="o">(</span><span class="m">1</span><span class="o">)</span>. Alice <alice@example.org>
gpg> expire
Modification de la date d’expiration de la clef principale.
Veuillez indiquer le temps pendant lequel cette clef devrait être valable.
<span class="nv">0</span> <span class="o">=</span> la clef n’expire pas
<n> <span class="o">=</span> la clef expire dans n jours
<n>w <span class="o">=</span> la clef expire dans n semaines
<n>m <span class="o">=</span> la clef expire dans n mois
<n>y <span class="o">=</span> la clef expire dans n ans
Pendant combien de temps la clef est-elle valable ? <span class="o">(</span><span class="m">0</span><span class="o">)</span> <span class="m">0</span>
La clef n’expire pas du tout
Est-ce correct ? <span class="o">(</span>o/N<span class="o">)</span> o
sec rsa2048/54B4CC7749CAE7C3
créé : <span class="m">2020</span>-05-13 expire : jamais utilisation : SC
confiance : ultime validité : ultime
ssb rsa2048/45EDD81BCE62E9BD
créé : <span class="m">2020</span>-05-13 expire : <span class="m">2022</span>-05-21 utilisation : E
<span class="o">[</span> ultime <span class="o">]</span> <span class="o">(</span><span class="m">1</span><span class="o">)</span>. Alice <alice@example.org></code></pre>
<p>Attention, comme on le voit ici seule la date d’expiration de la clef principale a été changée. Pour changer celle de la sous‑clef de chiffrement, il faut relancer la commande <code>expire</code> après avoir sélectionné ladite sous‑clef avec la commande <code>key</code> :</p>
<pre><code>gpg> key 1
sec rsa2048/54B4CC7749CAE7C3
créé : 2020-05-13 expire : jamais utilisation : SC
confiance : ultime validité : ultime
ssb* rsa2048/45EDD81BCE62E9BD
créé : 2020-05-13 expire : 2022-05-21 utilisation : E
[ ultime ] (1). Alice <alice@example.org>
</code></pre>
<p>La sous‑clef de chiffrement est maintenant sélectionnée (notez l’astérisque dans <code>ssb*</code>), on peut changer sa date d’expiration :</p>
<pre><code>gpg> expire
Modification de la date d’expiration d’une sous-clef.
Veuillez indiquer le temps pendant lequel cette clef devrait être valable.
0 = la clef n'expire pas
<n> = la clef expire dans n jours
<n>w = la clef expire dans n semaines
<n>m = la clef expire dans n mois
<n>y = la clef expire dans n ans
Pendant combien de temps la clef est-elle valable ? (0) 0
La clef n’expire pas du tout
Est-ce correct ? (o/N) o
sec rsa2048/54B4CC7749CAE7C3
créé : 2020-05-13 expire : jamais utilisation : SC
confiance : ultime validité : ultime
ssb* rsa2048/45EDD81BCE62E9BD
créé : 2020-05-13 expire : jamais utilisation : E
[ ultime ] (1). Alice <alice@example.org>
gpg> save
</code></pre>
<p>À noter que la date d’expiration d’une clef peut être changée à tout moment — y compris une fois que la clef a déjà expiré ! Donc même si vous vous réveillez le 21 mai 2022 et que vous vous rendez compte que vous avez oublié de prolonger la période de validité de votre clef et qu’elle a expiré hier, il n’est pas trop tard pour la changer.</p>
<p>Les changements de date d’expiration sont possibles dans tous les sens : on peut rendre « inexpirable » une clef qui avait auparavant une date d’expiration, tout comme on peut à l’inverse mettre une date d’expiration à une clef qui auparavant n’expirait jamais. Sitôt une nouvelle date d’expiration (y compris « pas de date d’expiration ») mise en place, les dates d’expirations précédentes sont complètement ignorées.</p>
<p>La seule contrainte est qu’il n’est pas possible de spécifier une date d’expiration postérieure au 7 février 2106 — c’est une limitation du format OpenPGP qui stocke les dates sous forme d’entiers non signés de 32 bits (or, 1ᵉʳ janvier 1970 + 2<sup>32</sup> secondes ≈ 7 février 2106). Mais si vous avez besoin d’une clef valable aussi longtemps, autant rendre la clef « inexpirable »…</p>
<p>Après avoir changé la date d’expiration d’une clef, il faut permettre à ses correspondants de prendre connaissance de la nouvelle date d’expiration, en republiant la clef via n’importe quel moyen qui a été utilisé pour la publier en premier lieu (par exemple, en la renvoyant vers un serveur de clefs avec <code>--send-keys</code>).</p>
<p>De manière générale, toute modification de la clef (ajout ou révocation d’une identité, ajout ou révocation d’une sous‑clef, changement des algorithmes préférés, changement de la date d’expiration) est une modification locale, qui n’a pas d’effets au‑delà de votre machine tant que vous ne republiez pas explicitement votre clef. À aucun moment GnuPG ne prendra l’initiative de transmettre vos modifications au monde extérieur.</p>
<p><em>N. B. — Le changement de la phrase de passe ne nécessite évidemment pas de republication, puisque cela ne concerne que la clef privée.</em></p>
<h2 id="toc-utilisation-dans-un-logiciel-ne-prenant-pas-en-charge-gpg">Utilisation dans un logiciel ne prenant pas en charge GPG</h2>
<p><em>N. D. M. : tiré de <a href="//linuxfr.org/nodes/120514/comments/1811839">ce fil de commentaires</a>.</em></p>
<p>Si l’on doit utiliser un client qui ne gère pas OpenPGP, ou une interface Web à laquelle on ne fait que moyennement confiance, il est possible de chiffrer, déchiffrer, signer ou vérifier un courriel autrement. Par exemple, en copiant le contenu depuis ou vers un fichier texte et en utilisant la ligne de commande <a href="https://www.gnupg.org/gph/en/manual/x110.html">via <code>gpg</code></a> ou en utilisant l’extension pour navigateur <a href="https://www.mailvelope.com/">Mailvelope</a>.</p>
<p>Pour le cas plus général d’un client (Web ou non) sans aucune prise en charge possible d’OpenPGP, oui, il est toujours possible en dernier recours de procéder aux opérations de chiffrement, déchiffrement et signature à l’extérieur du client. GPA, par exemple, a un mode « <em>clipboard</em> » (presse‑papiers), où vous pouvez écrire votre courriel, le chiffrer et/ou le signer, puis copier le résultat vers votre client (et inversement, vous pouvez y copier un message chiffré que vous avez reçu et l’y déchiffrer).</p>
<p>C’est quand même une solution du pauvre, et dans la mesure du possible changer de client serait recommandé, surtout si c’est un client lourd (qu’un <em>webmail</em> ne prenne pas en charge OpenPGP, ce n’est pas surprenant, mais un client lourd, ça pourrait largement être une raison suffisante pour le disqualifier d’office).</p>
<p>Un des gros problèmes de cette solution est qu’elle interdit pratiquement toute utilisation de PGP/MIME, sauf pour les fous furieux qui aiment construire et analyser des structures MIME « à la main ».</p>
<div class="footnotes">
<hr>
<ol>
<li id="fn1">
<p>Rien n’est encore décidé du côté des développeurs de GnuPG concernant l’entrée en vigueur du nouveau choix d’algorithme par défaut ; le plus probable est que cela arrivera dans la prochaine branche 2.3. <a href="#fnref1">↩</a></p>
</li>
<li id="fn2">
<p>L’identité et les motivations de l’attaquant sont pour autant que je sache inconnues à ce jour, mais la nature ciblée de l’attaque pointe vers certains utilisateurs mécontents vis‑à‑vis du principe de fonctionnement des serveurs SKS et qui voulaient ainsi démontrer avec force que le réseau était vulnérable. Si tel est le cas, c’est stupide à plus d’un titre. Ils n’ont rien démontré que la communauté ne sache pas déjà (la vulnérabilité du réseau aux empoisonnements était bien connue) ; ils ont surtout réussi à saper les quelques bonnes volontés qui restaient parmi les développeurs et administrateurs SKS ; leur action est équivalente à « je vais mettre le feu à cet immeuble d’habitation, ça prouvera à tout le monde que le promoteur a utilisé un revêtement inflammable — je ferai ça de nuit quand les occupants dormiront, la démonstration sera plus convaincante ». S’ils me lisent : vous êtes des connards. <a href="#fnref2">↩</a></p>
</li>
<li id="fn3">
<p>L’intégrité des développeurs d’Hagrid et administrateurs de <em>keys.openpgp.org</em> n’est pas en cause. Ce sont des membres reconnus de la communauté OpenPGP, il ne fait aucun doute qu’ils sont dignes de confiance. C’est l’idée même de devoir faire confiance à une entité centralisée qui me dérange, indépendamment des personnes qui sont derrière. <a href="#fnref3">↩</a></p>
</li>
<li id="fn4">
<p>Du moins, pas chiffrés de bout en bout par OpenPGP. Si le message est acheminé à travers des connexions SMTP chiffrées par TLS (ce qui est de plus en plus courant aujourd’hui), les en‑têtes sont chiffrés au même titre que le reste du message, en mode point à point. <a href="#fnref4">↩</a></p>
</li>
</ol>
</div>
</div><div><a href="https://linuxfr.org/news/bien-demarrer-avec-gnupg.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/120530/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/bien-demarrer-avec-gnupg#comments">ouvrir dans le navigateur</a>
</p>
gouttegdDavy DefaudBenoît Sibaudpatrick_gYsabeau 🧶 🧦https://linuxfr.org/nodes/120530/comments.atomtag:linuxfr.org,2005:Diary/391652020-05-21T14:55:07+02:002020-05-21T15:51:31+02:00Bien démarrer avec GnuPGLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<h2 class="sommaire">Sommaire</h2>
<ul class="toc">
<li><a href="#toc-installation-de-gnupg">Installation de GnuPG</a></li>
<li><a href="#toc-g%C3%A9n%C3%A9rer-sa-clef">Générer sa clef</a></li>
<li>
<a href="#toc-que-faire-apr%C3%A8s-avoir-cr%C3%A9%C3%A9-sa-clef">Que faire après avoir créé sa clef ?</a><ul>
<li><a href="#toc-sauvegarder-les-clefs">Sauvegarder les clefs</a></li>
<li><a href="#toc-mettre-%C3%A0-labri-le-certificat-de-r%C3%A9vocation">Mettre à l’abri le certificat de révocation</a></li>
</ul>
</li>
<li>
<a href="#toc-diffuser-la-clef-publique">Diffuser la clef publique</a><ul>
<li><a href="#toc-les-serveurs-de-clefs-sks">Les serveurs de clefs SKS</a></li>
<li><a href="#toc-le-serveur-keysopenpgporg">Le serveur keys.openpgp.org</a></li>
<li><a href="#toc-autres-m%C3%A9thodes-de-distribution">Autres méthodes de distribution</a></li>
</ul>
</li>
<li>
<a href="#toc-chiffrer-signer-des-fichiers">Chiffrer, signer des fichiers</a><ul>
<li><a href="#toc-chiffrer-un-fichier">Chiffrer un fichier</a></li>
<li><a href="#toc-signer-un-fichier">Signer un fichier</a></li>
<li><a href="#toc-d%C3%A9chiffrer-v%C3%A9rifier-un-fichier">Déchiffrer, vérifier un fichier</a></li>
</ul>
</li>
<li>
<a href="#toc-chiffrer-signer-des-e-mails">Chiffrer, signer des e-mails</a><ul>
<li><a href="#toc-obtenir-la-clef-dedward">Obtenir la clef d’Edward</a></li>
<li><a href="#toc-thunderbird-et-enigmail">Thunderbird et Enigmail</a></li>
<li><a href="#toc-neomutt">(Neo)Mutt</a></li>
<li><a href="#toc-autres-clients">Autres clients</a></li>
</ul>
</li>
</ul>
<p>Suite à une diatribe de ma part à l’encontre de la mauvaise qualité de beaucoup de tutoriels consacrés à GnuPG, <a href="//linuxfr.org/forums/general-general/posts/gpg-2-postes-et-1-yubikey#comment-1805704">on m’a suggéré</a> de créer le mien. Alors, <em>without further ado</em>, le voici.</p>
<h2 id="toc-installation-de-gnupg">Installation de GnuPG</h2>
<p>Si vous utilisez GNU/Linux, GnuPG est dans les dépôts de toutes les distributions, et il est très souvent installé par défaut.</p>
<p>Il peut être utile néanmoins de vérifier que la version installée est bien issue de la dernière branche stable (2.2.x), et non de la branche 1.4.x (qui n’est maintenue que pour la compatibilité avec les versions de PGP datant des années 1990) ou des branches 2.0.x/2.1.x (qui sont obsolètes).</p>
<p>Il est possible de faire cohabiter GnuPG 1.4 et GnuPG 2.2 sur le même système ; dans ce cas, assurez-vous que la version que vous utilisez en temps normal est bien la 2.2.</p>
<p>En 2020, il semble que sur la plupart des distributions GNU/Linux, demander l’installation d’un paquet <em>gnupg</em> installe bien GnuPG 2.2, le binaire correspondant étant disponible sous le nom <code>gpg</code>. Il y a quelques exceptions, comme par exemple Fedora, où <em>gnupg</em> installe GnuPG 1.4 — il faut demander l’installation de <em>gnupg2</em> pour avoir GnuPG 2.2, le binaire correspondant étant appelé <code>gpg2</code>.</p>
<blockquote>
<p>Dans le reste de cet article, je supposerai que <code>gpg</code> est le binaire de GnuPG 2.2 ; remplacez <code>gpg</code> par <code>gpg2</code> si besoin en fonction de votre distribution.</p>
</blockquote>
<p>Sous Windows, <a href="https://gpg4win.org/download.html">Gpg4Win</a> est la distribution GnuPG de référence. La version 3.1.11, à l’heure où ces lignes sont écrites, fournit GnuPG 2.2.17.</p>
<p>Sous Mac OS X, <a href="https://gpgtools.org/">GPG Suite</a> est une distribution fournissant GnuPG 2.2.17. GnuPG est aussi disponible via <a href="https://www.macports.org/">MacPorts</a>, sous le nom <em>gnupg2</em>.</p>
<h2 id="toc-générer-sa-clef">Générer sa clef</h2>
<p>Étape incontournable, la génération de la clef est malheureusement l’objet d’un volume considérable de désinformation. C’est l’étape où la plupart des « tutos » consacrés à GnuPG se fourvoient, et noient l’aspirant utilisateur sous une foule de « conseils » mal avisés, inutiles voire dangereux.</p>
<p>Alors, une bonne fois pour toutes : générer une clef, ça se fait en une seule étape, une seule commande :</p>
<pre><code>$ gpg --gen-key
GnuPG doit construire une identité pour identifier la clef.
Nom réel : Alice
Adresse électronique : alice@example.org
Vous avez sélectionné cette identité :
"Alice <alice@example.org>"
Changer le (N)om, l'(A)dresse électronique ou (O)ui/(Q)uitter ? o
De nombreux octets aléatoires doivent être générés. Vous devriez faire
autre chose (taper au clavier, déplacer la souris, utiliser les disques)
pendant la génération de nombres premiers ; cela donne au générateur de
nombres aléatoires une meilleure chance d’obtenir suffisamment d'entropie.
gpg: clef 54B4CC7749CAE7C3 marquée de confiance ultime
gpg: revocation certificate stored as '/home/alice/.gnupg/openpgp-revocs.d/7685DC4214D727BB011BD6B754B4CC7749CAE7C3.rev'
les clefs publique et secrète ont été créées et signées.
pub rsa2048 2020-05-13 [SC] [expires: 2022-05-13]
7685DC4214D727BB011BD6B754B4CC7749CAE7C3
uid Alice <alice@example.org>
sub rsa2048 2020-05-13 [E]
</code></pre>
<p>Oui, c’est tout. Ça n’a pas besoin d’être plus compliqué que ça. Non, il n’est pas nécessaire d’ajouter préalablement trente-cinq lignes dans le fichier de configuration de GnuPG pour changer les réglages par défaut. <em>La configuration par défaut de GnuPG est saine !</em> Les réglages par défaut ont été choisis comme tels pour de bonnes raisons. Vous ne devriez y toucher que si vous savez exactement <em>pourquoi</em> ils ne conviendraient pas à votre cas d’utilisation — pas parce qu’un <em>crypto-nerd</em> vous dit de le faire dans son billet de blog « générer une clef parfaite en dix-sept étapes ».</p>
<p>À quoi ressemble une clef générée en suivant les réglages par défaut ? C’est une clef principale RSA de 2048 bits, destinée aux opérations de signature, et une sous-clef de chiffrement similaire. Elle a une durée de validité de deux ans à compter de sa création, et est associée aux préférences d’algorithmes suivantes :</p>
<ul>
<li>pour le chiffrement : AES256, puis AES192, AES128, 3DES ;</li>
<li>pour la condensation : SHA2-512, puis SHA2-384, SHA2-256, SHA2-224, SHA-1 ;</li>
<li>pour la compression : ZLIB, puis BZIP2, ZIP, pas de compression.</li>
</ul>
<p>Une fois encore, ces préférences par défaut (qui ne datent pas d’hier — la plupart de ces réglages datent de 2009/2010) sont saines et n’ont pas besoin d’être modifiées.</p>
<p>Éventuellement, si l’idée d’une clef RSA de 2048 bits vous fait tiquer (ça ne devrait pas) et si vous êtes sûrs que vos correspondants utilisent tous des implémentations suffisamment modernes d’OpenPGP, vous pouvez opter pour une clef utilisant l’algorithme par défaut des prochaines versions de GnuPG<sup id="fnref1"><a href="#fn1">1</a></sup> :</p>
<pre><code>$ gpg --quick-gen-key 'Robert <bob@example.org>' future-default
Sur le point de créer une clef pour :
"Robert <bob@example.org>"
Faut-il continuer ? (O/n) o
De nombreux octets aléatoires doivent être générés. Vous devriez faire
autre chose (taper au clavier, déplacer la souris, utiliser les disques)
pendant la génération de nombres premiers ; cela donne au générateur de
nombres aléatoires une meilleure chance d’obtenir suffisamment d'entropie.
gpg: clef AC44CDC5733527A9 marquée de confiance ultime
gpg: revocation certificate stored as '/home/bob/.gnupg/openpgp-revocs.d/D7D0521F44673693DFFEB13FAC44CDC5733527A9.rev'
les clefs publique et secrète ont été créées et signées.
pub ed25519 2020-05-13 [SC] [expires: 2022-05-13]
D7D0521F44673693DFFEB13FAC44CDC5733527A9
uid Robert <bob@example.org>
sub cv25519 2020-05-13 [E]
</code></pre>
<p>Vous obtenez alors une clef principale de signature de type <code>ed25519</code> et une sous-clef de chiffrement de type <code>cv25519</code> ; comme leur nom le laisse supposer, ces clefs sont basées sur la courbe elliptique dite « 25519 » (<a href="https://tools.ietf.org/html/rfc7748">RFC 7748</a>).</p>
<blockquote>
<p>La courbe 25519 ne fait pas encore partie du standard OpenPGP, qui officiellement ne supporte pour l’instant que les courbes P-256, P-384, et P-521 du NIST (<a href="https://tools.ietf.org/html/rfc6637">RFC 6637</a>). Elle a néanmoins été ajoutée dès les premiers brouillons du RFC « 4880bis » (la prochaine version du standard) en 2016 et peut être utilisée dès maintenant sans crainte pour la compatibilité future.</p>
<p>En pratique, la courbe 25519 est supportée par la plupart des implémentations d’OpenPGP — à ma connaissance, au moins GnuPG (≥ 2.1), OpenPGP.js, Sequoia-PGP, et RNP. Déterminer si elle est supportée par « Broadcom Encryption Desktop » (héritier de Symantec PGP), en dénichant des informations techniques au milieu des arguments commerciaux de Broadcom, est laissé en exercice au lecteur.</p>
<p>Concrètement, vous ne devriez pas rencontrer de problèmes si vous choisissez d’utiliser l’option future-default, à moins que certains de vos correspondants n’utilisent toujours GnuPG ≤ 2.0 — auquel cas essayez de les convaincre de se mettre à jour, ce sera beaucoup plus productif que de suivre un tutoriel vous recommandant de générer une clef RSA de 8192 bits.</p>
</blockquote>
<p>Bien entendu, si la ligne de commande vous rebute, il est parfaitement possible de s’en passer. La manière exacte de générer une clef peut varier légèrement d’un frontal GnuPG à un autre (GPA, Seahorse, KGpg, etc.), mais les grandes lignes restent les mêmes et sont illustrées dans la .</p>
<blockquote>
<p>Dans le reste de cet article, je privilégierai la ligne de commande aux frontaux graphiques. Nul élitisme de ma part, c’est simplement que l’interface en ligne de commande est la même partout alors que chaque frontal a sa propre interface et qu’il n’est pas réaliste de les présenter tous — je reparlerai parfois de GPA parce que c’est le frontal que j’utilise, mais pour les autres, je vous renvoie à leur documentation.</p>
</blockquote>
<p><img src="//img.linuxfr.org/img/68747470733a2f2f696e63656e702e6f72672f66696c65732f6d6973632f323032302f6770612d6b657967656e2e706e67/gpa-keygen.png" alt="Fig1" title="Source : https://incenp.org/files/misc/2020/gpa-keygen.png"><br>
<strong>Figure 1.</strong> Les quatre étapes pour créer une clef avec GNU Privacy Assistant (GPA), le frontal officiel de GnuPG: saisissez votre nom <strong>(A)</strong>, votre adresse e-mail <strong>(B)</strong>, choisissez si vous voulez une copie de sauvegarde de votre future clef <strong>(C)</strong>, observez votre clef nouvellement créée <strong>(D)</strong>.</p>
<h2 id="toc-que-faire-après-avoir-créé-sa-clef">Que faire après avoir créé sa clef ?</h2>
<h3 id="toc-sauvegarder-les-clefs">Sauvegarder les clefs</h3>
<p>Sauf contraintes très particulières, vos clefs <em>doivent</em> être sauvegardées ; n’en gardez qu’une seule copie sur la machine où elles ont été créées et sont utilisées, c’est courir le risque de les perdre (et avec elles, les données dont elles dépendent) le jour où le disque dur rend l’âme ou la machine est perdue ou volée.</p>
<blockquote>
<p>S’il est possible d’adopter pour les clefs publiques une stratégie de sauvegarde torvaldienne (<em>i.e.</em> les « mettre sur un serveur FTP et laisser le reste du monde en faire des miroirs »), ce n’est évidemment pas le cas des clefs privées…</p>
</blockquote>
<p>Vous pourriez être tenté de faire une simple archive du dossier <code>.gnupg</code>, qui contient tous les fichiers manipulés par GnuPG (dont les trousseaux). Toutefois ce n’est pas nécessairement une bonne idée : le contenu exact de ce dossier est considéré comme un détail d’implémentation interne à GnuPG, qui à ce titre est susceptible de changer au fil des versions (par exemple, la manière de stocker les clefs sur le disque a radicalement changé entre GnuPG 2.0 et GnuPG 2.1). Il est préférable de n’utiliser que l’interface publique de GnuPG, qui générera un fichier au format standard OpenPGP, dont il est garanti qu’il sera lisible par n’importe quelle version future de GnuPG (ou par une autre implémentation conforme du standard, indépendante de GnuPG).</p>
<p>Comme entr’aperçu en Figure 1, si vous avez crée vos clefs avec GPA, vous avez pu choisir de créer automatiquement une copie de sauvegarde dès le début. Sinon, utilisez la commande suivante pour créer une telle copie :</p>
<pre><code>$ gpg -o backup.gpg --export-secret-keys alice@example.org
</code></pre>
<p>Contrairement à ce que le nom de la commande <code>--export-secret-keys</code> peut laisser supposer, le fichier <code>backup.gpg</code> ne contient pas que la partie secrète des clefs, mais aussi tous les éléments qui composent la clef publique. Ce fichier est donc suffisant à lui seul pour restaurer l’intégralité de vos clefs.</p>
<blockquote>
<p>Plus tard, lorsque vous aurez commencé à utiliser GnuPG pour échanger avec vos correspondants, vous aurez à sauvegarder deux éléments supplémentaires : les clefs publiques de vos correspondants et la confiance que vous leur accordez. Vous pouvez utiliser pour ça les deux commandes suivantes :</p>
<pre><code>$ gpg -o public-keys.gpg --export
$ gpg --export-ownertrust > trust.txt
</code></pre>
</blockquote>
<p>Ce que vous faites ensuite de votre copie de sauvegarde est de votre ressort. Notez qu’elle contient vos clefs privées sous leur forme protégée par votre phrase de passe (sauf si vous avez choisi de ne pas avoir de phrase de passe lors de la création de la clef), donc pour peu que ladite phrase de passe soit assez robuste quiconque mettrait la main sur votre sauvegarde ne serait pas pour autant en mesure d’utiliser vos clefs.</p>
<blockquote>
<p>Ah, et cela peut sembler évident, mais : ne stockez pas la copie de sauvegarde de votre clef privée sur un support chiffré avec la clef publique correspondante, qui nécessiterait la clef privée pour y accéder !</p>
</blockquote>
<p>Une option de sauvegarde que j’apprécie particulièrement et que je recommande est celle de la sauvegarde sur papier. L’outil <a href="http://www.jabberwocky.com/software/paperkey/">Paperkey</a> est spécialement conçu pour ça : donnez-lui votre copie de sauvegarde et il en fera une version imprimable :</p>
<pre><code>$ paperkey --secret-key backup.gpg | lpr
</code></pre>
<blockquote>
<p>Avoir des sauvegardes, c’est bien. Savoir les utiliser le jour où on en a besoin, c’est mieux. Les trois commandes suivantes restaurent successivement votre propre clef (parties publiques et privées), les clefs publiques de vos correspondants, et les informations de confiance :<br>
<code><br>
$ gpg --import backup.gpg<br>
$ gpg --import public-keys.gpg<br>
$ gpg --import-ownertrust < trust.txt<br>
</code></p>
<p>Si vous devez restaurer votre clef à partir de la sauvegarde sur papier générée par paperkey, numérisez le papier en question, passez-le à l’OCR pour obtenir un fichier texte (appelé <code>frompaper.txt</code> dans la commande ci-dessous), puis utilisez paperkey à nouveau pour reconstituer le fichier <code>backup.gpg</code> :<br>
<code><br>
$ paperkey --pubring public-keys.gpg --secrets frompaper.txt --output backup.gpg<br>
</code></p>
<p>Notez l’utilisation du fichier <code>public-keys.gpg</code>, dans lequel paperkey vient trouver les parties publiques de votre clef (qui sont absentes de la version imprimable).</p>
</blockquote>
<h3 id="toc-mettre-à-labri-le-certificat-de-révocation">Mettre à l’abri le certificat de révocation</h3>
<p>Un certificat de révocation vous permet de signaler à vos correspondants de ne plus utiliser votre clef publique, dans l’éventualité où vous ne seriez plus en mesure d’utiliser la clef privée correspondante — typiquement, soit parce que vous avez perdu la clef elle-même (je vous avais bien dit de faire une copie de sauvegarde…), soit parce que vous avez oublié la phrase de passe qui la protège.</p>
<p>De nombreux tutoriels vous enjoignent à créer un tel certificat immédiatement après avoir créé votre clef. Toutefois, c’est inutile. En effet, GnuPG l’a déjà fait pour vous, comme vous l’avez peut-être remarqué dans les sorties console plus haut :</p>
<pre><code>gpg: revocation certificate stored as '/home/alice/.gnupg/openpgp-revocs.d/7685DC4214D727BB011BD6B754B4CC7749CAE7C3.rev'
</code></pre>
<p>Vous le trouverez donc le dossier <code>.gnupg/openpgp-revocs.d</code>, dans un fichier nommé d’après l’empreinte de votre clef.</p>
<p>C’est probablement une bonne idée de stocker ce certificat ailleurs que sur la machine où vous avez déjà votre clef, puisque vous ne voulez pas perdre ce certificat en même temps que la clef elle-même. Attention, où que vous décidiez de le stocker, gardez à l’esprit que quiconque met la main dessus peut unilatéralement révoquer votre clef, sans avoir en sa possession la clef privée et sans la connaissance de la phrase de passe (c’est tout l’objet de ce certificat que de ne pas avoir besoin de la clef privée).</p>
<p>N’utilisez ce certificat de révocation <em>que</em> dans le cas où vous perdez l’usage de votre clef. Si vous en avez toujours l’usage et que vous souhaitez la révoquer pour une toute autre raison (par exemple, simplement parce que vous estimez qu’elle a fait son temps et que vous souhaitez la remplacer par une nouvelle, ou si vous craignez qu’elle n’ait été compromise), générez un certificat de révocation <em>ad hoc</em> au moment où vous en avez besoin :</p>
<pre><code>$ gpg -o revcert.asc --generate-revocation alice@example.org
sec rsa2048/54B4CC7749CAE7C3 2020-05-13 Alice <alice@example.org>
Faut-il créer un certificat de révocation pour cette clef ? (o/N) o
Choisissez la cause de la révocation :
0 = Aucune cause indiquée
1 = La clef a été compromise
2 = La clef a été remplacée
3 = La clef n'est plus utilisée
Q = Annuler
(Vous devriez sûrement sélectionner 1 ici)
Quelle est votre décision ? 2
Entrez une description facultative, en terminant par une ligne vide :
>
Cause de révocation : La clef a été remplacée
(Aucune description donnée)
Est-ce d'accord? (o/N) o
Sortie forcée avec armure ASCII.
Certificat de révocation créé.
Veuillez le déplacer sur un support que vous pouvez cacher ; toute personne
accédant à ce certificat peut l'utiliser pour rendre votre clef inutilisable.
Imprimer ce certificat et le stocker ailleurs est une bonne idée, au cas où le
support devienne illisible. Attention tout de même : le système d'impression
utilisé pourrait stocker ces données et les rendre accessible à d'autres.
</code></pre>
<p>L’avantage d’un certificat de révocation <em>ad hoc</em>, par rapport à un certificat « générique » généré préventivement à la création de la clef, est double. D’une part, comme illustré dans la sortie ci-dessus, il permet de spécifier la raison motivant la révocation ; d’autre part, dans les cas où la clef est révoquée pour une raison autre qu’une compromission (choix 2 ou 3 ci-dessus : clef remplacée ou plus utilisée), les signatures émises par la clef antérieurement à la révocation resteront valables, alors que dans le cas d’une clef révoquée sans raison explicitement spécifiée, <em>toutes</em> les signatures jamais émises par la clef sont remises en cause (comme dans le cas où la clef a été compromise).</p>
<p>Pour utiliser un certificat de révocation, importez-le simplement dans votre trousseau avec <code>gpg --import</code>. Attention, importer un certificat de révocation ne demande pas de confirmation et est irréversible.</p>
<h2 id="toc-diffuser-la-clef-publique">Diffuser la clef publique</h2>
<p>Maintenant que vous avez une clef, il vous faut mettre la partie publique à disposition de vos correspondants.</p>
<h3 id="toc-les-serveurs-de-clefs-sks">Les serveurs de clefs SKS</h3>
<p>Pendant longtemps, la méthode « classique » pour diffuser une clef publique a consisté à l’envoyer sur un des serveurs de clefs disponibles un peu partout sur Internet. Ces serveurs font typiquement partie d’un réseau au sein duquel les différentes instances se synchronisent régulièrement. Non seulement cela permet à l’utilisateur de ne pas se soucier du serveur auquel il s’adresse, mais cela fournit aussi une certaine résilience aussi bien face aux incidents (un des serveurs du réseau devient subitement inaccessible) que contre certaines interférences de gens mal intentionnés.</p>
<p>Malheureusement, aujourd’hui la survie à long terme du réseau des serveurs de clefs est incertaine. Il y a plusieurs raisons à cela, qui sortent du cadre de cet article, mais on peut citer pêle-mêle : quasiment pas de développeurs motivés pour travailler sur le logiciel serveur de référence (<a href="https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Home">SKS-Keyserver</a>), un réseau entièrement dépendant de la bonne volonté des administrateurs (tous les nœuds sont gérés bénévolement), des désaccords dans la communauté sur les fonctionnalités que doit ou ne doit pas offrir un serveur de clefs, un principe de fonctionnement qui rend les serveurs vulnérables aux empoisonnements… C’est notamment ce dernier point qui a en 2019 porté un coup probablement fatal au réseau, avec une attaque par empoisonnement visant quelques membres influents de la communauté.<sup id="fnref2"><a href="#fn2">2</a></sup></p>
<p>Quelles que soient les raisons, le fait est qu’il n’y a plus à l’heure où j’écris ces lignes qu’à peine une vingtaine de serveurs dans le pool principal <a href="https://sks-keyservers.net/status/">sks-keyservers.net</a>, contre facilement plus d’une centaine habituellement. Le réseau est toujours utilisable <em>pour l’instant</em>, mais il faut se préparer à ne plus pouvoir compter dessus dans un futur plus ou moins proche.</p>
<p>Pour l’instant donc, GnuPG est toujours configuré pour utiliser le pool sks-keyservers.net par défaut, alors tant que le pool est vivant et si vous acceptez une certaine incertitude sur la disponibilité, vous n’avez rien de particulier à faire. Pour envoyer votre clef sur un des serveurs du réseau, faites simplement :</p>
<pre><code>$ gpg --send-keys alice@example.org
</code></pre>
<h3 id="toc-le-serveur-keysopenpgporg">Le serveur keys.openpgp.org</h3>
<p>Un nouveau serveur de clefs a récemment vu le jour, en partie en réaction aux déboires du réseau SKS: <a href="https://keys.openpgp.org/">keys.openpgp.org</a>. Il utilise non pas SKS-Keyserver, mais <a href="https://gitlab.com/hagrid-keyserver/hagrid">Hagrid</a> (le « gardien des clefs » de Poudlard), un serveur de clefs basé sur Sequoia-PGP (une bibliothèque OpenPGP en Rust).</p>
<p>Bien qu’il puisse être considéré comme un remplaçant ou un successeur du réseau SKS, plusieurs différences importantes sont à noter avant de décider de l’utiliser.</p>
<p>Il s’agit d’<em>un</em> serveur, non d’un pool. Même si n’importe qui peut monter son propre serveur Hagrid (tout comme avec SKS), il n’y a aucune synchronisation possible entre serveurs (contrairement à SKS, pour lequel c’est même une fonctionnalité majeure). Même si les développeurs affirment qu’une certaine décentralisation est prévue à l’avenir, ils préviennent que quelle que soit la forme que prendra cette décentralisation il ne sera pas question d’une « fédération ouverte » similaire à SKS (ce qui personnellement me fait m’interroger sur ce que peut être une fédération « fermée » — d’autant que contrairement à ce qu’ils semblent suggérer, n’entrait déjà pas dans le pool SKS qui veut). Le serveur <code>keys.openpgp.org</code> est donc un <em>single point of failure</em>, et un <em>single point of attack</em>.</p>
<p>Hagrid vérifie les adresses e-mail lorsqu’une clef est déposé sur le serveur, afin que seul le titulaire d’une adresse ne puisse déposer une clef associée à cette adresse. Le but étant à la fois de permettre à chacun de garder le contrôle sur ce qui est publié par le serveur, et d’offrir la garantie qu’une clef trouvée sur le serveur appartient bien à qui elle prétend appartenir (deux garanties jamais offertes par les serveurs classiques, par conception). C’est sympathique, mais cela implique que le serveur est de fait analogue à une autorité de certification à laquelle vous devez faire confiance, une idée qui personnellement ne me plaît guère.<sup id="fnref3"><a href="#fn3">3</a></sup></p>
<p>Dernier point et pas des moindres, Hagrid viole délibérément le standard OpenPGP dans certaines situations (notamment pour la diffusion des certificats de révocation), en diffusant des paquets de clef publique associés à aucune identité — ce que le standard ne permet pas. Cela conduit les implémentations conformes à refuser certains paquets en provenance d’un serveur Hagrid. Ce n’est pas un « bug de GnuPG » comme le laisse entendre la FAQ de <code>keys.openpgp.org</code>.</p>
<p>Cela étant dit, si vous souhaitez utiliser ce serveur pour y chercher des clefs, il vous suffit d’ajouter la ligne suivante dans le fichier <code>~/.gnupg/dirmngr.conf</code> :</p>
<pre><code>keyserver hkps://keys.openpgp.org
</code></pre>
<p>et de relancer le démon réseau de GnuPG, <em>dirmngr</em> :</p>
<pre><code>$ gpgconf --reload dirmngr
</code></pre>
<p>Pour <em>déposer</em> une clef en revanche, la commande <code>--send-keys</code> de GnuPG ne suffit pas, puisqu’elle ne permet pas à Hagrid de vérifier l’adresse (ce n’est pas prévu par le protocole HKP, utilisé par GnuPG derrière cette commande). À la place, il vous faut exporter la clef :</p>
<pre><code>$ gpg -o alice.pub --export alice@example.org
</code></pre>
<p>puis télécharger le fichier <code>alice.pub</code> sur <a href="https://keys.openpgp.org/upload">keys.openpgp.org/upload</a>, et suivre les instructions d’Hagrid pour procéder à la vérification d’adresse.</p>
<blockquote>
<p>Si vous utilisez le greffon Enigmail pour Thunderbird, il utilise déjà <code>keys.openpgp.org</code> par défaut et implémente l’API spécifique de Hagrid (en remplacement du protocole HKP), lui permettant de procéder à la vérification d’adresse en arrière-plan sans intervention de l’utilisateur.</p>
</blockquote>
<h3 id="toc-autres-méthodes-de-distribution">Autres méthodes de distribution</h3>
<p>D’autres méthodes existent pour assurer la diffusion des clefs publiques, notamment la publication dans le DNS (DANE, <a href="https://tools.ietf.org/html/rfc7929">RFC 7929</a>) et dans un <em>Web Key Directory</em> (<a href="https://www.ietf.org/id/draft-koch-openpgp-webkey-service-09.txt">WKD</a>). Pour ces deux méthodes je vous renvoie à un <a href="//linuxfr.org/users/gouttegd/journaux/de-la-distribution-des-clefs-openpgp">précédent journal</a> ; néanmoins la mise en œuvre de DANE et de WKD dépend de celui qui contrôle le domaine de votre adresse e-mail (votre fournisseur d’accès à Internet ou de messagerie, votre employeur, votre université…) — à moins que vous ne disposiez de votre propre domaine, décider d’utiliser DANE ou WKD n’est pas vraiment de votre ressort.</p>
<p>Au-delà des méthodes formalisées de distribution (serveurs de clefs décentralisés ou non, DANE, WKD), vous pouvez (devez ?) aussi distribuer votre clef par tous les moyens possibles et imaginables. La poster sur un forum, sur votre blog, dans votre profil Facebook (il y a un champ dédié à cet usage), etc.</p>
<p>Là où il n’est pas pratique de publier la clef proprement dite faute de place, n’hésitez pas à publier <em>a minima</em> son empreinte : sur votre profil Twitter ou Mastodon (ou n’importe quel autre type de réseau dit « social »), sur vos cartes de visite, en signature de vos messages sur les forums où vous intervenez, etc.</p>
<p>Pour obtenir l’empreinte d’une clef (dont la vôtre), demandez simplement à GnuPG d’afficher ladite clef :</p>
<pre><code>$ gpg -k alice@incenp.org
pub rsa2048 2020-05-13 [SC]
7685DC4214D727BB011BD6B754B4CC7749CAE7C3
uid [ ultime ] Alice <alice@example.org>
sub rsa2048 2020-05-13 [E]
</code></pre>
<h2 id="toc-chiffrer-signer-des-fichiers">Chiffrer, signer des fichiers</h2>
<p>Cette section passe rapidement en revue la manière d’utiliser GnuPG sur des fichiers locaux, sans communication avec l‘extérieur.</p>
<h3 id="toc-chiffrer-un-fichier">Chiffrer un fichier</h3>
<p>Pour chiffrer un fichier à votre propre intention, la commande de base est la suivante :</p>
<pre><code>$ gpg -r alice@example.org -e lorem.txt
</code></pre>
<p>L’option <code>-r UID</code> (ou <code>--recipient UID</code>) indique la clef publique avec laquelle chiffrer le fichier. Elle attend en paramètre l’identité (UID, <em>User ID</em>) associée à la clef que vous voulez utiliser. Ici, il s’agit de la vôtre (en supposant, comme dans tout le reste de ce journal, que vous êtes Alice). Notez que vous n’avez pas nécessairement besoin de spécifier l’identité en entier, dès lors qu’il n’y a aucune ambiguïté : si votre trousseau de clefs publiques ne contient qu’une seule clef dont l’identité associée contient la chaîne « alice », alors <code>-r alice</code> sera suffisant (dans le cas contraire, si plusieurs clefs peuvent correspondre, GnuPG sélectionnera arbitrairement la première qu’il trouve dans le trousseau, qui ne sera peut-être pas celle que vous vouliez).</p>
<p>Si vous prévoyez de chiffrer des fichiers à votre intention assez fréquemment, vous pouvez envisager d’ajouter l’option <code>default-recipient-self</code> dans le fichier de configuration de GnuPG (<code>~/.gnupg/gpg.conf</code>) ; elle conduira GnuPG à sélectionner votre propre clef publique par défaut si vous ne spécifiez aucune clef explicitement. Avec cette option en place, la commande ci-dessus devient simplement :</p>
<pre><code>$ gpg -e lorem.txt
</code></pre>
<p>Le paramètre <code>-e</code> (ou <code>--encrypt</code>) est la commande de chiffrement. Elle attend simplement le nom du fichier à chiffrer, dans le cas présent <code>lorem.txt</code>. Cette commande produira un fichier <code>lorem.txt.gpg</code>, contenant la version chiffrée du fichier précédent.</p>
<blockquote>
<p>Quelle que soit l’opération que vous demandez à GnuPG (chiffrer, signer, déchiffrer), vous pouvez toujours utiliser l’option <code>-o</code> (ou <code>--output</code>) pour spécifier explicitement le nom du fichier de sortie.</p>
</blockquote>
<h3 id="toc-signer-un-fichier">Signer un fichier</h3>
<p>Il y a trois commandes différentes pour effectuer une signature, qui correspondent aux trois types de signature possibles.</p>
<ul>
<li>La signature « standard » (faute d’un meilleur nom pour la désigner). Demandée avec la commande <code>-s</code> (ou <code>--sign</code>), elle produit un fichier contenant à la fois le document qui a été signé (enveloppé dans un paquet OpenPGP) <em>et</em> la signature correspondante.</li>
<li>La signature en clair (<em>cleartext signature</em>), avec la commande <code>--clear-sign</code>. Elle produit aussi un fichier contenant à la fois le document original et sa signature, mais ici le document original n’est pas enveloppé dans un paquet OpenPGP et reste sous une forme textuelle lisible. Ce type de signature n’est utile que si le document original à signer est lui-même de type texte, une signature en clair sur un document binaire n’a aucun sens.</li>
<li>La signature détachée, avec la commande <code>-b</code> (ou <code>--detach-sign</code>). Elle produit un fichier ne contenant <em>que</em> la signature, sans le document original ; lors de la vérification, le document original doit être fourni à GnuPG en même temps que la signature détachée. Ce type de signature est typiquement utilisé pour signer les archives de code source, l’avantage dans ce cas de figure étant que ceux qui ne sont pas intéressés par la vérification de la signature peuvent utiliser l’archive directement, sans avoir à l’extraire de son enveloppe OpenPGP comme dans le cas d’une signature « normale ».</li>
</ul>
<p>Il est possible de signer <em>et</em> chiffrer en même temps en combinant les commandes <code>-s</code> et <code>-e</code>. Dans ce cas, le fichier produit contient à la fois le document chiffré et la signature correspondante. Ce n’est possible que pour les signatures « standard », combiner chiffrement et signature en clair ou détachée n’a pas de sens.</p>
<p>Toutes les commandes de signature utilisent par défaut la première clef trouvée dans le trousseau de clefs secrètes. La plupart des utilisateurs n’ont normalement qu’une seule clef secrète (compte non tenu des sous-clefs), donc ce comportement convient la plupart du temps. Si néanmoins vous avez plusieurs clefs secrètes, vous pouvez ajouter l’option <code>default-key UID1</code> dans le fichier de configuration de GnuPG pour toujours signer avec la clef associée à l’identité <em>UID1</em>, ou utiliser l’option <code>-u UID2</code> sur la ligne de commande pour ponctuellement signer avec la clef associée à l’identité <em>UID2</em>.</p>
<p>Les commandes de signatures produisent par défaut un fichier portant le même nom que le fichier à signer plus une extension dépendant du type de signature :<code>.gpg</code> pour une signature normale, <code>.asc</code> pour une signature en clair, <code>.sig</code> pour une signature détachée. Ces extensions sont purement conventionnelles et n’ont aucune signification pour GnuPG, qui identifie les fichiers qu’il manipule sur la base du type de paquets OpenPGP qu’ils contiennent et non sur leur extension.</p>
<h3 id="toc-déchiffrer-vérifier-un-fichier">Déchiffrer, vérifier un fichier</h3>
<p>La commande <code>-d</code> (ou <code>--decrypt</code>) déchiffre un fichier :</p>
<pre><code>$ gpg -d lorem.txt.gpg
gpg: chiffré avec une clef RSA de 2048 bits, identifiant 45EDD81BCE62E9BD, créée le 2020-05-13
"Alice <alice@example.org>
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Ut purus
[...]
</code></pre>
<p>Notez l’asymétrie entre les commandes de chiffrement (<code>-e</code>) et de déchiffrement (<code>-d</code>) : la première produit un fichier, tandis que la seconde écrit par défaut sur la sortie standard.</p>
<p>Si le fichier <code>lorem.txt.gpg</code> était un fichier chiffré et signé, GnuPG vérifiera la signature en même temps qu’il déchiffrera, et affichera le résultat à la fin de l’opération :</p>
<pre><code>$ gpg -d lorem.txt.gpg
gpg: chiffré avec une clef RSA de 2048 bits, identifiant 45EDD81BCE62E9BD, créée le 2020-05-13
"Alice <alice@example.org>
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Ut purus
[...]
gpg: Signature faite le mar. 19 mai 2020 23:23:21 BST
gpg: avec la clef RSA 7685DC4214D727BB011BD6B754B4CC7749CAE7C3
gpg: Bonne signature de « Alice <alice@example.org> » [ultime]
</code></pre>
<p>La commande <code>-d</code>, malgré son nom, s’utilise aussi sur un fichier signé uniquement, pour vérifier la signature et extraire le document signé de son enveloppe OpenPGP et le rendre ainsi utilisable.</p>
<p>On utilisera la commande <code>--verify</code> pour vérifier une signature en clair…</p>
<pre><code>$ gpg --verify lorem.txt.asc
gpg: Signature faite le mar. 19 mai 2020 23:34:22 BST
gpg: avec la clef RSA 7685DC4214D727BB011BD6B754B4CC7749CAE7C3
gpg: Bonne signature de « Alice <alice@example.org> » [ultime]
</code></pre>
<p>… ainsi que pour vérifier une signature détachée. Dans ce cas, GnuPG attend en premier argument le fichier de signature proprement dit, et en second argument le document original (en l’absence de cet argument GnuPG cherchera un fichier portant le même nom que le fichier de signature moins l’extension <code>.sig</code>, mais il est préférable de spécifier le fichier explicitement) :</p>
<pre><code>$ gpg --verify lorem.txt.siglorem.txt
gpg: Signature faite le mar. 19 mai 2020 23:41:52 BST
gpg: avec la clef RSA 7685DC4214D727BB011BD6B754B4CC7749CAE7C3
gpg: Bonne signature de « Alice <alice@example.org> » [ultime]
</code></pre>
<p>Il est aussi possible d’utiliser la commande <code>--verify</code> sur une signature « standard », mais dans ce cas, GnuPG ne fera <em>que</em> vérifier la signature, sans extraire le document signé contrairement à ce que fait la commande <code>-d</code>.</p>
<p><img src="//img.linuxfr.org/img/68747470733a2f2f696e63656e702e6f72672f66696c65732f6d6973632f323032302f6770612d66696c656f70732e706e67/gpa-fileops.png" alt="Fig2" title="Source : https://incenp.org/files/misc/2020/gpa-fileops.png"><br>
<strong>Figure 2.</strong> Exemples d’opérations sur des fichiers avec GPA. Pour chiffrer et un fichier, ouvrez-le dans le <em>File Manager</em> <strong>(A)</strong> et cliquez sur le bouton correspondant dans la barre d’outils. Dans la fenêtre de dialogue qui s’ouvre <strong>(B)</strong>, sélectionnez la clef publique avec laquelle chiffrer le document, et éventuellement la clef privée avec laquelle le signer. En <strong>(C)</strong>, un exemple du résultat d’une vérification de signature.</p>
<h2 id="toc-chiffrer-signer-des-e-mails">Chiffrer, signer des e-mails</h2>
<p>Pour finir, il est temps d’utiliser GnuPG pour ce pour quoi il est en principe conçu (même si en vrai vous l’utilisez bien pour ce que vous voulez…), à savoir chiffrer et signer des e-mails.</p>
<p>Si vous n’avez pas d’amis, vous pouvez toujours envoyer un mail à <em>Edward</em>, un <em>bot</em> mis en place par la Free Software Foundation pour permettre aux gens d’essayer le chiffrement des e-mails.</p>
<h3 id="toc-obtenir-la-clef-dedward">Obtenir la clef d’Edward</h3>
<p>La première étape pour établir une communication chiffrée, que ce soit avec Edward ou n’importe qui d’autre, est d’obtenir la clef publique de votre correspondant.</p>
<p>Cherchez donc la clef d’Edward sur les serveurs de clefs, et importez-là :</p>
<pre><code>$ gpg --search-keys edward-fr@fsf.org
gpg: data source: http://pgp.surf.nl:11371
(1) Edward, el simpático robot GnuPG <edawrd-es@fsf.org>
Edward the GPG Bot <edward@fsf.org>
Edward, the GPG Bot <edward-en@fsf.org>
Edward, le gentil robot de GnuPG <edward-fr@fsf.org>
[…]
2048 bit RSA key 9FF2194CC09A61E8, créé : 2014-06-29
Keys 1-1 of 1 for "edward-fr@fsf.org". Entre le ou les nombres, (S)uivant, ou (Q)uitter > 1
gpg: clef 9FF2194CC09A61E8 : clef publique « Edward, el simpático robot GnuPG <edward-es@fsf.org> » importée
gpg: Quantité totale traitée : 1
gpg: importées : 1
</code></pre>
<p>Si vous avez choisi, dans la section relative aux serveurs de clefs, d’utiliser le nouveau serveur <code>keys.openpgp.org</code>, la clef d’Edward n’y est malheureusement pas disponible. Dans ce cas, vous pouvez utiliser l’option <code>--keyserver</code> sur la ligne de commande pour ponctuellement ignorer le serveur que vous avez configuré dans <code>~/.gnupg/dirmngr.conf</code> :</p>
<pre><code>$ gpg --keyserver hkp://pool.sks-keyservers.net --search-keys edward-fr@fsf.org
</code></pre>
<p>En cas de problème avec le réseau SKS, une copie de la clef est incluse ci-dessous :</p>
<pre><code>-----BEGIN PGP PUBLIC KEY BLOCK-----
mQENBFOwfzoBCADpwK6sGC3EUzgD7IW1X5ZDR1nC5/rcXacAJLarPpvQBEz4pwjT
joAzATM7F9RwIzJ3hJTZHiYaQY4cfiGlKSnrd8GPC8A4QkxXIaQ0hLpcsBSbtZJp
o2iOzL2fRHmW2ZlnSHXPKbDwx5p0NcdQfjL9i2Yo31aLIO/Chhn5uyvIznOjaCSC
/O6x2C4m81Lu+B4UTDpl8y6ChtphUxyFGd7RXDXmkYQrxVqJbXKuSVmNMhM09myG
7iQ1l0YLOcCxa3IXDqQkte49BhMGB9wl4eDTE86HEzRjMtdhFpbTOW/+1N4XkOUV
y42HzGtmSAttojpIp00foNlWn1sn7JZJ18ojABEBAAG0NEVkd2FyZCwgbGUgZ2Vu
dGlsIHJvYm90IGRlIEdudVBHIDxlZHdhcmQtZnJAZnNmLm9yZz6JATgEEwECACIF
AlOxd9YCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEJ/yGUzAmmHorAwI
AI/THdk1Lj0IoYxGzOxGq1j2l1iRa2JcKNdsj0PzSpDHjtycCqJZrjBWAMJRymBt
WHeS6KLw992cEbmZ7wh0ObFXSicDTBOTAu3xwjNIRATAlH3f5nPNMnyULiNUbQin
naU7zOr/Iq88onb3FrjqhGETdxGXBm6RgoWGX7vdzdgY99CnC5bTt3TCu+9ddzVJ
NxS3yycwPl4IlRaSyQHQIMMRVs3p0e/8cqtZDBzsMOLPtoRGFoYBo3/pZWwF7kFX
n6u/z7UzuvW+COYtU2wIdSVkdmpn9jWl4+7UgKOXprDcQmrdGiCeErUxPbpWikza
VvVQkruAG9skMjuSk0Cmmai5AQ0EU7B/OgEIAMJfFthcYpgykvEHCBVm6vpMof1E
xuQ1bxNI1KVs2GTXF2sn9dXa6RvM6dz9xferglaZnsG+j7ACVaEHsgqe/E0VjhIS
NP1sJgH4dtyoL06dWp6Bs8SdI1Jasm+h55cXgYagahNpub1TUxjpsu8ZsyM/5cRp
B2HCmCXIsTYPEwIQu77XMpNo+mRi8oguOJ44ZMIYrvzivrJh1GnCbimSFfj7eMoF
1SHwl+e+k8reDqnoIWp514NGo9LLlwGIG0TQcg9S/tIchibmMZOV+xSS+MFxpMvm
eWCrgVJdK2paJ4d+8ZaxvkRDEtfGbmTOr7dFfA8i1heIPcbw4ejZEHGKWesAEQEA
AYkBHwQYAQIACQUCU7B/OgIbDAAKCRCf8hlMwJph6O+7CADBAYe5gTjFsA+vwVNt
gwrYXQv/w1XIndFUsOO3T7NjfTVETd652kIU4zFJRf3ebXbxz3E+1f1qPuVD8WJ9
5Roeyl8nsEoxr+iB6+/FqRIbHMnC0qqYRjVYvtD5ezgNpqGy/3dJmrhOuj7JHKIm
aB6tALq6JWb5URDHU5tCHPCyBJQhuMGBZzzyAexmBSk2CiKLX9DyX36ZO2+vlQK4
X0FW1M4qrC1gEB7sEpP9xTsST7MZr9USevwRcbRd/GvPFpTnI6JWazAmnhoRyOEA
ld6ORPNW1EUPBsIhfazP3v5SG5NXDAjYMHH/MbX872FhoBWerfHpi1yyZPHSkkXI
UAaY
=/0NJ
-----END PGP PUBLIC KEY BLOCK-----
</code></pre>
<p>Copiez-là dans un fichier puis importez-là manuellement :</p>
<pre><code>$ gpg --import edward.asc
</code></pre>
<p>Une fois la clef d’Edward dans votre trousseau public, il faut la signer pour la marquer comme valide (je vous renvoie à un <a href="//linuxfr.org/users/gouttegd/journaux/de-la-confiance-dans-le-monde-openpgp">précédent journal</a> pour plus de détails sur la notion de validité, et notamment pour savoir en quoi le fait de signer une clef la rend valide). Pour ça, lancez l’éditeur de clefs sur la clef d’Edward :</p>
<pre><code>$ gpg --edit-key edward-fr@fsf.org
pub rsa2048/9FF2194CC09A61E8
créé : 2014-06-29 expire : jamais utilisation : SC
confiance : inconnu validité : inconnu
sub rsa2048/469DDF6D9014D2D6
créé : 2014-06-29 expire : jamais utilisation : E
[ inconnue] (1). Edward, el simpático robot GnuPG <edward-es@fsf.org>
[ inconnue] (2) Edward the GPG Bot <edward@fsf.org>
[ inconnue] (3) Edward, the GPG Bot <edward-en@fsf.org>
[ inconnue] (4) Edward, le gentil robot de GnuPG <edward-fr@fsf.org>
[…]
</code></pre>
<p>Affichez l’empreinte complète de la clef et vérifiez qu’elle correspond à l’empreinte dans la sortie ci-dessous :</p>
<pre><code>gpg> fpr
pub rsa2048/469DDF6D9014D2D6 2014-06-29 Edward, el simpático robotGnuPG <edward-es@fsf.org>
Empreinte clef princip. : F357 AA1A 5B1F A42C FD9F E52A 9FF2 194C C09A 61E8
</code></pre>
<p>Si l’empreinte correspond, vous pouvez procéder à la signature :</p>
<pre><code>gpg> sign
Voulez-vous vraiment signer toutes les identités ? (o/N) o
pub rsa2048/9FF2194CC09A61E8
créé : 2014-06-29 expire : jamais utilisation : SC
confiance : inconnu validité : inconnu
Empreinte clef princip. : F357 AA1A 5B1F A42C FD9F E52A 9FF2 194C C09A 61E8
Edward, el simpático robot GnuPG <edwardes@fsf.org>
Edward the GPG Bot <edward@fsf.org>
Edward, the GPG Bot <edward-en@fsf.org>
Edward, le gentil robot de GnuPG <edward-fr@fsf.org>
[…]
Voulez-vous vraiment signer cette clef avec votre
clef « Alice <alice@example.org> » (54B4CC7749CAE7C3)
Voulez-vous vraiment signer ? (o/N) o
gpg> save
</code></pre>
<h3 id="toc-thunderbird-et-enigmail">Thunderbird et Enigmail</h3>
<p>Si vous utilisez le client e-mail <a href="https://www.thunderbird.net/">Thunderbird</a>, vous devez (pour l’instant) installer le greffon <a href="https://enigmail.net/">Enigmail</a> pour y ajouter la prise en charge d’OpenPGP, Thunderbird ne supportant nativement que S/MIME. Cherchez Enigmail depuis le gestionnaire de greffons de Thunderbird, puis installez-le.</p>
<blockquote>
<p>Enigmail ne fonctionnera plus à partir de Thunderbird 78, dont la sortie est prévue d’ici la fin de l’année 2020. À la place, la nouvelle version de Thunderbird <a href="https://blog.thunderbird.net/2019/10/thunderbird-enigmail-and-openpgp/">prendra nativement en charge OpenPGP</a> sans qu’un greffon ne soit nécessaire.</p>
<p>L’étendue de cette prise en charge native reste encore à voir, mais elle sera probablement, au moins dans l’immédiat, <a href="https://wiki.mozilla.org/Thunderbird:OpenPGP:2020">plus limitée</a> que ce qui est actuellement offert par Enigmail.</p>
<p>Une chose semble déjà sûre, Thunderbird n’utilisera pas les trousseaux de GnuPG (pas plus le trousseau public que le trousseau privé). Il sera possible d’importer les clefs de GnuPG vers Thunderbird, mais une fois cela fait, les clefs importées seront gérées par Thunderbird indépendamment de GnuPG — toute modification faite dans GnuPG sera invisible depuis Thunderbird et inversement.</p>
<p>À titre personnel, je trouve que c’est une très mauvaise idée. Et je suis globalement assez dubitatif de l’approche consistant à jeter à la poubelle une implémentation pleinement fonctionnelle pour après coup se rendre que compte que « oh ben zut, il y avait des fonctionnalités utiles en fait, bon comment on fait pour les ré-implémenter <em>from scratch</em> maintenant ? », comme par exemple avec le <a href="https://mail.mozilla.org/pipermail/tb-planning/2019-December/007288.html">support des cartes OpenPGP</a>.</p>
<p>L’avenir dira si cette orientation aura permis d’attirer de nouveaux utilisateurs ou si elle aura surtout fait fuir les utilisateurs déjà existants. /rant</p>
</blockquote>
<p><img src="//img.linuxfr.org/img/68747470733a2f2f696e63656e702e6f72672f66696c65732f6d6973632f323032302f656e69676d61696c2e706e67/enigmail.png" alt="Fig3" title="Source : https://incenp.org/files/misc/2020/enigmail.png"><br>
<strong>Figure 3.</strong> Utilisation d’Enigmail dans Thunderbird. <strong>(A)</strong> Sitôt installé, Enigmail détecte votre installation de GnuPG et vos clefs pré-existantes. <strong>(B)</strong> Envoi d’un e-mail chiffré et signé à Edward, auquel on joint une copie de sa propre clef publique. <strong>(C)</strong> Réception et déchiffrement de la réponse automatique d’Edward.</p>
<p>Une fois Enigmail installé, il devrait automatiquement détecter GnuPG et vous proposer de se configurer pour utiliser la clef que vous avez déjà ; acceptez en cliquant sur <em>Apply my keys</em> (Figure 3A).</p>
<blockquote>
<p>Si vous installez Enigmail sans avoir préalablement généré vous-même votre clef, Enigmail en générera silencieusement une pour vous mais se configurera automatiquement pour utiliser <em>p≡p</em> plutôt que GnuPG. Sans rentrer dans les détails, <a href="https://www.pep.security/">p≡p</a> est une solution de chiffrement opportuniste, basée entre autres sur OpenPGP mais où, en gros, l’utilisateur ne contrôle plus rien… L’utilisation de p≡p a parfois été appelée <em>Junior mode</em>, mais ce terme ne semble plus apparaître dans la documentation ou l’interface de Enigmail.</p>
</blockquote>
<p>Vous pouvez maintenant envoyer un mail à <code>edward-fr@fsf.org</code> (Figure 3B). Par défaut le message sera signé, et comme la clef publique d’Edward est déjà dans votre trousseau, Enigmail devrait reconnaître son adresse et aussi activer le chiffrement. Si vous voulez qu’Edward puisse chiffrer également sa réponse à votre intention, pensez à joindre votre propre clef publique au message, en utilisant l’option appropriée dans le menu d’Enigmail.</p>
<blockquote>
<p>Lors de l’envoi, il se peut qu’Enigmail vous propose une option appelé <em>protected headers</em>, qui vise à chiffrer certains en-têtes du message (notamment l’objet) et non seulement le corps du message. Je déconseille personnellement cette option qui repose sur une <a href="https://www.ietf.org/id/draft-autocrypt-lamps-protected-headers-02.txt">proposition de standard</a> à mon sens beaucoup trop complexe pour le bénéfice qu’elle apporte, et dont le support par un grand nombre de clients de messagerie est incertain. Gardez plutôt à l’esprit que les en-têtes ne sont <em>pas</em> chiffrés,<sup id="fnref4"><a href="#fn4">4</a></sup> et abstenez-vous de divlguer trop d’informations dans les objets de vos messages.</p>
</blockquote>
<p>Après quelques minutes, vous devriez recevoir une réponse automatique d’Edward. Vous aurez ainsi confirmation que tout s’est bien passé (Figure 3C). Félicitations, vous venez de procéder à votre premier échange d’e-mails chiffrés.</p>
<h3 id="toc-neomutt">(Neo)Mutt</h3>
<p>Si vous utilisez le client <a href="http://mutt.org/">Mutt</a> ou le <em>fork</em> <a href="https://neomutt.org/">Neomutt</a>, tous deux prennent nativement en charge OpenPGP et ne nécessitent qu’un minimum de configuration. Ajoutez simplement les deux lignes suivantes à votre fichier <code>mutrc</code> :</p>
<pre><code>set crypt_use_gpgme = yes
set pgp_default_key = 0x7685DC4214D727BB011BD6B754B4CC7749CAE7C3
</code></pre>
<p>La première ligne configure (Neo)Mutt pour utiliser la bibliothèque GpgME pour interagir avec GnuPG (ce qui est la manière recommandée par les développeurs de GnuPG), au lieu d’appeler le binaire <code>gpg</code> directement (ce qui est toujours possible mais <em>error-prone</em>). La seconde ligne indique la clef à utiliser par défaut ; cette clef sera utilisée pour signer vos messages, et pour en chiffrer une copie à votre intention (afin que vous puissiez toujours déchiffrer les messages envoyés à des tiers). Remplacez la valeur indiquée par l’empreinte de votre propre clef.</p>
<p><img src="//img.linuxfr.org/img/68747470733a2f2f696e63656e702e6f72672f66696c65732f6d6973632f323032302f6e656f6d7574742e706e67/neomutt.png" alt="Fig4" title="Source : https://incenp.org/files/misc/2020/neomutt.png"><br>
<strong>Figure 4.</strong> Utilisation de Neomutt. <strong>(A)</strong> Préparation d’un message chiffré et signé dans Neomutt. <strong>(B)</strong> Le menu PGP permettant de sélectionner si un message doit être chiffré, signé, signé avec une clef autre que celle configurée par défaut, chiffré <em>et</em> signé. <strong>(C)</strong> Le menu de sélection de la clef publique du destinataire.</p>
<p>Une fois (Neo)Mutt configuré, envoyez donc un mail à Edward. Préparez le message de la manière habituelle jusqu’à arriver à la fenêtre d’envoi (Figure 4A). Par défaut le message sera seulement signé, appuyez sur la touche <code>p</code> pour appeler le menu PGP (Figure 4B) puis sur la touche <code>b</code> comme indiqué pour demander que le message soit chiffré et signé.</p>
<p>Attachez au message une copie de votre clef publique en tapant <code>Esc-k</code> et en sélectionnant votre clef dans le menu correspondant. Au moment d’envoyer le message, vous serez invité à sélectionner la clef publique avec laquelle chiffrer le message (Figure 4C), parmi les clefs associées à une adresse correspondant à celle du destinataire du message. Sélectionnez la clef d’Edward (qui logiquement devrait être la seule, vous ne devriez pas avoir plus d’une clef associée à l’adresse <code>edward-fr@fsf.org</code>), puis envoyez.</p>
<p>Attendez quelques minutes de recevoir la réponse d’Edward et vérifiez que tout s’est bien passé.</p>
<h3 id="toc-autres-clients">Autres clients</h3>
<p>Il ne serait pas réaliste de vouloir couvrir tous les clients e-mail existants et je n’essayerai même pas.</p>
<p>Beaucoup de clients libres ont un support natif pour OpenPGP : GNOME Evolution, KMail, Claws-Mail… En général, ils n’opposent pas de difficultés majeures.</p>
<p>Sous Windows, la distribution Gpg4Win déjà mentionnée dans la première section est fournie avec <em>GpgOL</em>, un greffon pour Microsoft Outlook.</p>
<p>Sous Mac OS X, GPG Suite fournit un greffon pour Apple Mail appelé <em>GPG Mail</em>. Attention, ce greffon est libre (comme le reste de GPG Suite) mais, depuis peu, payant.</p>
<p>Sous Android, <a href="https://www.openkeychain.org/">OpenKeychain</a> apporte la prise en charge d’OpenPGP à plusieurs applications, dont le client de messagerie <a href="https://k9mail.github.io/">K-9 Mail</a>.</p>
<blockquote>
<p>À titre personnel, il est hors de question que j’accepte de stocker une quelconque clef privée sur un téléphone Android. Je ne recommande l’utilisation d’OpenKeychain que couplée à un jeton cryptographique comme la <a href="https://www.yubico.com/product/yubikey-5-nfc">Yubibey 5 NFC</a>.</p>
</blockquote>
<div class="footnotes">
<hr>
<ol>
<li id="fn1">
<p>Rien n’est encore décidé du côté des développeurs de GnuPG concernant l’entrée en vigueur du nouveau choix d’algorithme par défaut ; le plus probable est que cela arrivera dans la prochaine branche 2.3. <a href="#fnref1">↩</a></p>
</li>
<li id="fn2">
<p>L’identité et les motivations de l’attaquant sont pour autant que je sache inconnues à ce jour, mais la nature ciblée de l’attaque pointe vers certains utilisateurs mécontents vis-à-vis du principe de fonctionnement des serveurs SKS et qui voulaient ainsi démontrer avec force que le réseau était vulnérable. Si tel est le cas, c’est stupide à plus d’un titre. Ils n’ont rien démontré que la communauté ne sache pas déjà (la vulnérabilité du réseau aux empoisonnements était bien connue) ; ils ont surtout réussi à saper les quelques bonnes volontés qui restaient parmi les développeurs et administrateurs SKS ; leur action est équivalente à « je vais mettre le feu à cet immeuble d’habitation, ça prouvera à tout le monde que le promoteur a utilisé un revêtement inflammable — je ferai ça de nuit quand les occupants dormiront, la démonstration sera plus convaincante ». S’ils me lisent : vous êtes des connards. <a href="#fnref2">↩</a></p>
</li>
<li id="fn3">
<p>L’intégrité des développeurs d’Hagrid et administrateurs de <code>keys.openpgp.org</code> n’est pas en cause. Ce sont des membres reconnus de la communauté OpenPGP, il ne fait aucun doute qu’ils sont dignes de confiance. C’est l’idée même de devoir faire confiance à une entité centralisée qui me dérange, indépendamment des personnes qui sont derrière. <a href="#fnref3">↩</a></p>
</li>
<li id="fn4">
<p>Du moins, pas chiffrés de bout en bout par OpenPGP. Si le message est acheminé à travers des connexions SMTP chiffrées par TLS (ce qui est de plus en plus courant aujourd’hui), les en-têtes sont chiffrés au même titre que le reste du message, en mode point-à-point. <a href="#fnref4">↩</a></p>
</li>
</ol>
</div>
<div><a href="https://linuxfr.org/users/gouttegd/journaux/bien-demarrer-avec-gnupg.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/120514/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/gouttegd/journaux/bien-demarrer-avec-gnupg#comments">ouvrir dans le navigateur</a>
</p>
gouttegdhttps://linuxfr.org/nodes/120514/comments.atomtag:linuxfr.org,2005:News/391972019-04-28T12:28:25+02:002019-04-28T12:28:25+02:00Nouvelles versions logicielles du projet GNU en avril 2019Licence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<div><p>Le projet GNU diffuse tous les mois la liste des nouvelles versions de ses logiciels. Jetons‐y un coup d’œil pour découvrir de nouveaux logiciels inconnus (de moi), des infâmes bogues disparus ou les promesses de solutions à tous nos besoins ; bref, de nouvelles versions annoncées allant de la corrective mineure à la version attendue depuis des années ; et l’on va donc parler de <code>dico</code>, <code>emacs</code>, <code>gama</code>, <code>gawk</code>, <code>gnuastro</code>, <code>gnuhealth-client</code>, <code>gnunet</code>, <code>gnupg</code>, <code>gnutls</code>, <code>libcdio</code>, <code>nano</code>, <code>parallel</code>, <code>rush</code>, <code>taler</code>, <code>shepherd</code> et <code>wget</code>.</p>
</div><ul><li>lien nᵒ 1 : <a title="https://www.fsf.org/blogs/community/gnu-spotlight-with-mike-gerwitz-15-new-gnu-releases-in-april" hreflang="en" href="https://linuxfr.org/redirect/103986">GNU Spotlight with Mike Gerwitz: 15 new GNU releases in April! </a></li><li>lien nᵒ 2 : <a title="https://linuxfr.org/news/nouvelles-versions-logicielles-du-projet-gnu-juin-et-juillet-2017" hreflang="fr" href="https://linuxfr.org/redirect/103987">Nouvelles versions logicielles du projet GNU juin et juillet 2017</a></li></ul><div><h2 class="sommaire">Sommaire</h2>
<ul class="toc">
<li>
<a href="#toc-dico-29"></a><a href="https://puszcza.gnu.org.ua/software/dico/dico.html">dico-2.9</a>
</li>
<li>
<a href="#toc-emacs-262"></a><a href="https://www.gnu.org/software/emacs/index.html#Releases">emacs-26.2</a>
</li>
<li>
<a href="#toc-gama-204"></a><a href="https://www.gnu.org/software/gama/">gama-2.04</a>
</li>
<li>
<a href="#toc-gawk-500"></a><a href="https://www.gnu.org/software/gawk/">gawk-5.0.0</a>
</li>
<li>
<a href="#toc-gnuastro-09"></a><a href="https://www.gnu.org/software/gnuastro/">gnuastro-0.9</a>
</li>
<li>
<a href="#toc-gnuhealth-client-344"></a><a href="http://health.gnu.org/">gnuhealth-client-3.4.4</a>
</li>
<li>
<a href="#toc-gnunet-0113"></a><a href="https://gnunet.org/fr/index.html">gnunet-0.11.3</a>
</li>
<li>
<a href="#toc-gnupg-2215"></a><a href="https://lists.gnupg.org/pipermail/gnupg-announce/2019q1/000436.html">gnupg-2.2.15</a>
</li>
<li>
<a href="#toc-gnutls-367"></a><a href="https://lists.gnupg.org/pipermail/gnutls-help/2019-March/004497.html">gnutls-3.6.7</a>
</li>
<li>
<a href="#toc-libcdio-210"></a><a href="https://www.gnu.org/software/libcdio/libcdio.html">libcdio-2.1.0</a>
</li>
<li>
<a href="#toc-nano-41-et-nano-42"></a><a href="https://www.nano-editor.org/news.php">nano-4.1 et nano-4.2</a>
</li>
<li>
<a href="#toc-parallel-20190422"></a><a href="https://www.gnu.org/software/parallel/">parallel-20190422</a>
</li>
<li>
<a href="#toc-rush-19"></a><a href="https://puszcza.gnu.org.ua/software/rush/">rush-1.9</a>
</li>
<li>
<a href="#toc-shepherd-060"></a><a href="https://www.gnu.org/software/shepherd/">shepherd-0.6.0</a>
</li>
<li>
<a href="#toc-wget-1202-et-wget-1203"></a><a href="https://www.gnu.org/software/wget/">wget-1.20.2 et wget-1.20.3</a>
</li>
<li><a href="#toc-conclusion">Conclusion</a></li>
</ul>
<h2 id="toc-dico-29"><a href="https://puszcza.gnu.org.ua/software/dico/dico.html">dico-2.9</a></h2>
<p>Dico est serveur de dictionnaire utilisé pour le protocole de communication DICT, sous GPL 3.0 et LGPL 2.1. Il est « <a href="https://puszcza.gnu.org.ua/software/dico/manual/dico.html">Dédié à la mémoire de Jacques Brel</a> » (on ne sait pas s’il s’y connaissait en <a href="https://tools.ietf.org/html/rfc2229">RFC 2229</a>). La version précédente était parue en février 2019. Cette version corrige la compilation sur les systèmes 32 bits et offre une option pour changer le chemin du fichier contenant le l’identifiant de processus (PID).</p>
<h2 id="toc-emacs-262"><a href="https://www.gnu.org/software/emacs/index.html#Releases">emacs-26.2</a></h2>
<p>Emacs est un éditeur polyvalent, dont la version précédente datait de mai 2018. Les nouveautés sont la possibilité de construire les modules en dehors de l’arbre des sources, d’être compatible avec Unicode 11, et la commande « Z » dans Dired (<em>Directory editor</em>) pour compresser tous les fichiers d’un répertoire.</p>
<p><img src="//img.linuxfr.org/img/68747470733a2f2f7777772e676e752e6f72672f736f6674776172652f656d6163732f696d616765732f656d6163732e706e67/emacs.png" alt="Logo Emacs" title="Source : https://www.gnu.org/software/emacs/images/emacs.png"></p>
<h2 id="toc-gama-204"><a href="https://www.gnu.org/software/gama/">gama-2.04</a></h2>
<p>La version précédente de ce logiciel d’ajustement des réseaux géodésiques était parue en février 2019. Cette version amène une prise en charge expérimentale de qmake lorsque CMake n’est pas disponible sur Windows, ajoute la fonction de hachage pour PointID et quelques corrections formelles mineures.</p>
<h2 id="toc-gawk-500"><a href="https://www.gnu.org/software/gawk/">gawk-5.0.0</a></h2>
<p>La version précédente de cette implémentation GNU du langage de traitement de lignes <em>awk</em> était parue en février 2018. Cette version majeure apporte la prise en charge de <code>%a</code> et <code>%A</code> dans <code>printf</code>, une amélioration de l’infrastructure de test, le remplacement des expressions rationnelles par celles de GNULIB, une mise à jour des dépendances de compilation, le retrait d’une fonction non documentée pour gérer des caractères non latins, le retrait de l’option <code>--with-whiny-user-strftime</code>, une meilleure prise en charge de l’environnement C99, <code>PROCINFO["platform"]</code> pour retenir la plate‐forme de compilation, un changement de comportement causant une erreur en cas d’utilisation de non‐variables dans SYMTAB, une réécriture de la gestion des commentaires, les espaces de nommage, l’utilisation des locales pour ignorer la casse sur les <em>locales</em> à un octet, et de nombreuses corrections de bogues.</p>
<h2 id="toc-gnuastro-09"><a href="https://www.gnu.org/software/gnuastro/">gnuastro-0.9</a></h2>
<p>La version précédente de cet ensemble d’utilitaires pour l’astronomie était parue en décembre 2018. Dans la longue liste des changements, l’option <code>--checkconfig</code>, de nouveaux opérateurs et fonctions, des opérations à multiples fils d’exécution pour divers opérateurs, diverses évolutions et de nombreuses corrections de bogues.</p>
<h2 id="toc-gnuhealth-client-344"><a href="http://health.gnu.org/">gnuhealth-client-3.4.4</a></h2>
<p>La version précédente de ce progiciel libre dans le domaine de la santé datait de janvier 2019. Il s’agit d’une version corrective. GNU Health est basé sur Tryton.</p>
<h2 id="toc-gnunet-0113"><a href="https://gnunet.org/fr/index.html">gnunet-0.11.3</a></h2>
<p>Plusieurs versions de ce réseau et ensemble d’outils permettant une communication sécurisée, décentralisée et résistante à la censure sont parues depuis février 2019 (0.11.0). Il s’agit d’une version corrective.</p>
<p><img src="//img.linuxfr.org/img/68747470733a2f2f676e756e65742e6f72672f7374617469632f696d616765732f676e756e65742d616e6f6e796d6f75732d6c6f676f2e706e67/gnunet-anonymous-logo.png" alt="Logo gnunet" title="Source : https://gnunet.org/static/images/gnunet-anonymous-logo.png"></p>
<h2 id="toc-gnupg-2215"><a href="https://lists.gnupg.org/pipermail/gnupg-announce/2019q1/000436.html">gnupg-2.2.15</a></h2>
<p>GnuPG est un programme en ligne de commande qui permet de signer, chiffrer et déchiffrer les données et les communications. Il s’agit d’une version de maintenance.</p>
<p><img src="//img.linuxfr.org/img/68747470733a2f2f676e7570672e6f72672f73686172652f6c6f676f2d676e7570672d6c696768742d707572706c652d62672e706e67/logo-gnupg-light-purple-bg.png" alt="Logo gnupg" title="Source : https://gnupg.org/share/logo-gnupg-light-purple-bg.png"></p>
<h2 id="toc-gnutls-367"><a href="https://lists.gnupg.org/pipermail/gnutls-help/2019-March/004497.html">gnutls-3.6.7</a></h2>
<p>Cette bibliothèque pour gérer les protocoles SSL, TLS et DTLS connaît une version de corrections de bogues, dont des correctifs de sécurité. Elle amène une affectation à <em>NULL</em> des pointeurs libérés par <code>gnutls_free</code>, une correction d’un double <em>free</em> GNUTLS-SA-2019-03-27, une correction d’un accès à un pointeur invalide GNUTLS-SA-2019-03-27, un meilleur contrôle des limitations d’usage des clefs dans TLS 1.3, une facilitation des connexions TLS 1.3 multiples, diverses corrections (sur la vérification des paramètres de certificat, sur l’exécution en parallèle (<em>multithread</em>) en cas de faux départ, etc.) et une option <code>-logfile</code> pour rediriger la sortie standard.</p>
<h2 id="toc-libcdio-210"><a href="https://www.gnu.org/software/libcdio/libcdio.html">libcdio-2.1.0</a></h2>
<p>La version précédente de cette bibliothèque de gestion des CD (les galettes de polycarbonate) datait du 31 décembre 2017. Cette version dite <em>Mercredi de Pâques</em> est corrective, tout en ajoutant un pilote pour OpenBSD.</p>
<h2 id="toc-nano-41-et-nano-42"><a href="https://www.nano-editor.org/news.php">nano-4.1 et nano-4.2</a></h2>
<p>L’éditeur de texte <em>nano</em> a connu en avril deux versions baptisées « <em>¿Qué corchos será eso?</em> » et « <em>Tax the rich, pay the teachers</em> », pour éviter un plantage sur un « <em>spell</em> » manquant, améliorer le renvoi à la ligne des lignes longues, ajouter le retour chariot final dans un fichier, lire les fichiers de syntaxe par ordre alphabétique, améliorer la coloration syntaxique du préprocesseur en C, désactiver les commandes externes pendant la visualisation et corriger divers bogues.</p>
<pre><code> ::: The
iLE88Dj. :jD88888Dj:
.LGitE888D.f8GjjjL8888E; .d8888b. 888b 888 888 888
iE :8888Et. .G8888. d88P Y88b 8888b 888 888 888
;i E888, ,8888, 888 888 88888b 888 888 888
D888, :8888: 888 888Y88b 888 888 888
D888, :8888: 888 88888 888 Y88b888 888 888
D888, :8888: 888 888 888 Y88888 888 888
D888, :8888: Y88b d88P 888 Y8888 Y88b. .d88P
888W, :8888: "Y8888P88 888 Y888 "Y88888P"
W88W, :8888:
W88W: :8888: 88888b. 8888b. 88888b. .d88b.
DGGD: :8888: 888 "88b "88b 888 "88b d88""88b
:8888: 888 888 .d888888 888 888 888 888
:W888: 888 888 888 888 888 888 Y88..88P
:8888: 888 888 "Y888888 888 888 "Y88P"
E888i
tW88D Text Editor Homepage
</code></pre>
<h2 id="toc-parallel-20190422"><a href="https://www.gnu.org/software/parallel/">parallel-20190422</a></h2>
<p>Cet outil <em>shell</em> permet d’exécuter des tâches en parallèle sur un ou plusieurs ordinateurs. La version du mois est baptisée <em>Invitation</em> et amène une invitation pour les dix ans du projet en 2020, des corrections de bogues et une mise à jour des pages de manuel.</p>
<p><img src="//img.linuxfr.org/img/68747470733a2f2f7777772e676e752e6f72672f736f6674776172652f706172616c6c656c2f6c6f676f2d677261792b626c61636b3330302e706e67/logo-gray+black300.png" alt="Logo" title="Source : https://www.gnu.org/software/parallel/logo-gray+black300.png"></p>
<h2 id="toc-rush-19"><a href="https://puszcza.gnu.org.ua/software/rush/">rush-1.9</a></h2>
<p>La dernière version de ce shell restreint (<em>Restricted User Shell</em>) datait d’octobre 2016. Cette version amène la référence aux groupes parenthésés dans les expressions rationnelles, les variables définies par l’utilisateur, les syntaxes shell comme <code>VAR:-WORD</code>, <code>VAR:=WORD</code>, <code>VAR:?WORD</code> et <code>VAR:+WORD</code>, et la réécriture du script <code>rush-po</code> pour l’internationalisation.</p>
<h2 id="toc-shepherd-060"><a href="https://www.gnu.org/software/shepherd/">shepherd-0.6.0</a></h2>
<p>La précédente version de GNU Shepherd, le berger à <em>daemons</em> (anciennement <em>dmd</em>), date de septembre 2018. Cette version apporte le lancement <em>une seule fois</em>, l’absence d’erreur à l’arrêt d’un service s’il est déjà arrêté, un code non nul en cas d’erreur, la non‐prise en compte du redémarrage dans un conteneur et des améliorations des traductions (plus une nouvelle langue : le tamoul).</p>
<h2 id="toc-wget-1202-et-wget-1203"><a href="https://www.gnu.org/software/wget/">wget-1.20.2 et wget-1.20.3</a></h2>
<p>La précédente version de ce client HTTP, HTTPS et FTP datait de décembre 2018. Ces deux versions corrigent un cas de nouvel essai dans l’authentification NTLM et un débordement de tampon.</p>
<h2 id="toc-conclusion">Conclusion</h2>
<p>Dans une dépêche précédente, la question était « Y a‐t‐il un intérêt à écrire une telle dépêche ? ». À titre personnel, la réponse était oui, et d’après les commentaires, d’autres personnes étaient intéressées. N’hésitez donc pas à participer à sa rédaction et aux dépêches à venir.</p>
</div><div><a href="https://linuxfr.org/news/nouvelles-versions-logicielles-du-projet-gnu-en-avril-2019.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/117069/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/nouvelles-versions-logicielles-du-projet-gnu-en-avril-2019#comments">ouvrir dans le navigateur</a>
</p>
Benoît SibaudZeroHeureDavy DefaudPierre Jarillonhttps://linuxfr.org/nodes/117069/comments.atomtag:linuxfr.org,2005:News/384872018-04-15T23:27:50+02:002018-04-17T10:30:29+02:00GnuPG, OpenPGP.js & cie : quoi de neuf ?Licence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<div><p>Le 8 mars 2018, la version 3.0.0 de la bibliothèque OpenPGP.js sortait. Elle implémente le format OpenPGP en JavaScript et est disponible sous licence LGPL 3.0. C’est l’occasion de présenter cette bibliothèque et les nouveautés apportées par cette version. C’est surtout un très bon prétexte pour parler du standard OpenPGP lui‐même, de ses principales implémentations et de ses évolutions futures.</p></div><ul><li>lien nᵒ 1 : <a title="https://tools.ietf.org/html/rfc4880" hreflang="en" href="https://linuxfr.org/redirect/101587">Le standard OpenPGP (RFC 4880)</a></li><li>lien nᵒ 2 : <a title="https://tools.ietf.org/id/draft-ietf-openpgp-rfc4880bis-04.txt" hreflang="en" href="https://linuxfr.org/redirect/101752">Brouillon du prochain standard OpenPGP (RFC 4880bis)</a></li><li>lien nᵒ 3 : <a title="https://linuxfr.org/news/gnupg-utilise-gnupg-oublie-mais-gnupg-finance" hreflang="fr" href="https://linuxfr.org/redirect/101780">Dépêche sur la campagne de financement participatif pour GnuPG de 2015</a></li><li>lien nᵒ 4 : <a title="https://linuxfr.org/users/gouttegd/journaux/gnupg-lance-une-nouvelle-campagne-de-financement" hreflang="fr" href="https://linuxfr.org/redirect/101781">Journal sur la campagne de financement participatif pour GnuPG de 2017</a></li><li>lien nᵒ 5 : <a title="https://linuxfr.org/users/gouttegd/journaux/de-la-gestion-des-clefs-openpgp" hreflang="fr" href="https://linuxfr.org/redirect/101782">Journal sur la gestion des clés OpenPGP</a></li><li>lien nᵒ 6 : <a title="https://linuxfr.org/users/gouttegd/journaux/de-la-distribution-des-clefs-openpgp" hreflang="fr" href="https://linuxfr.org/redirect/101783">Journal sur la distribution des clés OpenPGP</a></li><li>lien nᵒ 7 : <a title="https://linuxfr.org/users/spack/journaux/gnupg-et-authentification-ssh" hreflang="fr" href="https://linuxfr.org/redirect/101784">Journal sur l’authentification SSH avec GnuPG</a></li><li>lien nᵒ 8 : <a title="https://gnupg.org/" hreflang="en" href="https://linuxfr.org/redirect/101785">GnuPG</a></li><li>lien nᵒ 9 : <a title="https://github.com/openpgpjs/openpgpjs/" hreflang="en" href="https://linuxfr.org/redirect/101786">GitHub OpenPGP.js</a></li></ul><div><h2 class="sommaire">Sommaire</h2>
<ul class="toc">
<li>
<a href="#openpgp">OpenPGP</a><ul>
<li><a href="#un-bref-historique-dopenpgp">Un bref historique d’OpenPGP</a></li>
<li><a href="#les-nouveaut%C3%A9s-%C3%A0-venir">Les nouveautés à venir</a></li>
</ul>
</li>
<li>
<a href="#quelques-impl%C3%A9mentations-dopenpgp">Quelques implémentations d’OpenPGP</a><ul>
<li><a href="#pgp">PGP</a></li>
<li><a href="#gnupg">GnuPG</a></li>
<li><a href="#rnp-ex-openpgpsdk--netpgp">RNP (ex OpenPGPSDK / NetPGP)</a></li>
<li><a href="#autres-impl%C3%A9mentations">Autres implémentations</a></li>
</ul>
</li>
<li>
<a href="#openpgpjs">OpenPGP.js</a><ul>
<li>
<a href="#loption-openpgpconfigaead_protect-anatomie-dune-mauvaise-id%C3%A9e">L’option openpgp.config.aead_protect, anatomie d’une mauvaise idée</a><ul>
<li><a href="#openpgp-et-lint%C3%A9grit%C3%A9-des-messages-chiffr%C3%A9s">OpenPGP et l’intégrité des messages chiffrés</a></li>
<li><a href="#les-propositions-du-groupe-de-travail-openpgp">Les propositions du groupe de travail OpenPGP</a></li>
<li><a href="#et-openpgpjs-l%C3%A0-dedans">Et OpenPGP.js là-dedans ?</a></li>
</ul>
</li>
<li>
<a href="#les-nouveaut%C3%A9s-dopenpgpjs-304">Les nouveautés d’OpenPGP.js 3.0.4</a><ul>
<li><a href="#prise-en-charge-des-courbes-elliptiques">Prise en charge des courbes elliptiques</a></li>
<li><a href="#masquage-de-lidentit%C3%A9-du-destinataire">Masquage de l’identité du destinataire</a></li>
<li><a href="#les-changements-sous-le-capot">Les changements sous le capot</a></li>
</ul>
</li>
</ul>
</li>
</ul><h2 id="openpgp">OpenPGP</h2>
<p>OpenPGP est un standard IETF visant à garantir l’interopérabilité entre logiciels de sécurisation de données, aussi bien en repos qu’en transit. Le nom vient du logiciel PGP (<em>Pretty Good Privacy</em>), écrit au début des années 1990 par Phil Zimmermann.</p>
<p>OpenPGP n’est pas un <em>protocole</em>, c’est un <em>format</em> (pensez, par exemple, à la différence entre HTTP et HTML). Le standard décrit le format des données manipulées par PGP (ou tout autre logiciel compatible avec ce standard). Il ne se préoccupe pas de savoir comment ces données sont échangées d’un logiciel à un autre — que cela se fasse par courrier électronique, par copie de fichiers à travers le <a href="http://www.catb.org/%7Eesr/jargon/html/S/sneakernet.html">sneakernet</a>, ou par <a href="https://tools.ietf.org/html/rfc1149">IP sur transporteurs aviaires</a>, c’est indifférent pour OpenPGP.</p>
<p>Cette distinction est fondamentale et explique, entre autres, pourquoi OpenPGP ne permet pas la <em>confidentialité persistante</em> (<em>forward privacy</em> en VO), cette fonctionnalité nécessitant un échange synchrone entre les deux parties à la communication (donc un <em>protocole</em> de communication entre les logiciels aux deux extrémités).</p>
<p>Le format OpenPGP peut être utilisé pour :</p>
<ul>
<li>
<em>chiffrer</em> des données afin de garantir leur <em>confidentialité</em> : seules les personnes autorisées peuvent lire les données ;</li>
<li>
<em>signer</em> des données afin de garantir leur <em>intégrité</em> — personne ne peut modifier les données subrepticement — et leur <em>authenticité</em> : on peut vérifier que les données proviennent bien de leur émetteur supposé ;</li>
<li>
<em>authentifier</em> des utilisateurs.</li>
</ul><p>Les briques élémentaires du format OpenPGP sont les <em>paquets</em>. Toutes les données manipulées par un logiciel comme PGP sont représentées sous la forme de paquets. Il existe des paquets pour représenter, par exemple, une clef cryptographique, un nom d’utilisateur, une signature, ou encore un « <em>blob</em> » de données arbitraires (typiquement le texte chiffré et/ou signé).</p>
<p>Une suite de paquets constitue un <em>message OpenPGP</em>. Par exemple, un courrier électronique chiffré, sous sa forme la plus simple, est un message constitué d’un paquet contenant une clef de session symétrique (chiffrée avec la clef publique du destinataire) suivi d’un paquet contenant le corps du courrier électronique (chiffré avec la clef de session). Ce message au <em>format</em> OpenPGP sera probablement acheminé avec le <em>protocole</em> SMTP, IMAP, ou POP3.</p>
<h3 id="un-bref-historique-dopenpgp">Un bref historique d’OpenPGP</h3>
<p>La première version du standard est sortie en 1996 (<a href="https://tools.ietf.org/html/rfc1991">RFC 1991</a>), elle décrit le format des messages de PGP 2.6. Deux ans plus tard paraît la seconde version (<a href="https://tools.ietf.org/html/rfc2440">RFC 2440</a>), basée sur PGP 5 et qui introduit plusieurs changements majeurs (dont le nom <em>OpenPGP</em> lui‐même, qui ne figurait pas dans le RFC 1991) :</p>
<ul>
<li>l’algorithme de condensation MD5 est déclaré obsolète, SHA-1 est recommandé à la place ;</li>
<li>le format de clef v3, utilisant des empreintes MD5, est remplacé par un nouveau format v4, utilisant des empreintes SHA-1 ;</li>
<li>il est désormais possible d’ajouter des <em>sous‐clefs</em> à une clef <em>maître</em> (ou <em>primaire</em>) ;</li>
<li>on peut désormais certifier une clef avec une <a href="//linuxfr.org/users/gouttegd/journaux/de-la-confiance-dans-le-monde-openpgp#notion-de-trust-signature"><em>trust signature</em></a>.</li>
</ul><p>En 2007, le standard est rafraîchi sous la forme du <a href="https://tools.ietf.org/html/rfc4880">RFC 4880</a>. Les principaux changements sont l’introduction officielle des algorithmes de chiffrement AES (la compétition AES n’était pas encore terminée lors de la publication du RFC 2440) et des algorithmes de condensation de la famille SHA-2. Depuis, deux autres RFC sont venus enrichir le standard avec des algorithmes supplémentaires : le <a href="https://tools.ietf.org/html/rfc6637">RFC 6637</a> (algorithmes de cryptographie à clef publique basés sur les courbes elliptiques) et le <a href="https://tools.ietf.org/html/rfc5581">RFC 5581</a> (algorithme de chiffrement Camellia).</p>
<h3 id="les-nouveautés-à-venir">Les nouveautés à venir</h3>
<p>Une nouvelle révision du standard, temporairement désignée <em>RFC 4880bis</em>, est aujourd’hui en cours de préparation. Les principaux changements prévus, tels qu’ils figurent dans le <a href="https://tools.ietf.org/id/draft-ietf-openpgp-rfc4880bis-04.txt">dernier brouillon</a>, sont :</p>
<ul>
<li>un nouveau format de clef, v5, associé à des empreintes SHA-256 ;</li>
<li>un nouveau paquet pour les données chiffrées en mode « chiffrement authentifié » (AEAD, <em>Authenticated Encryption with Associated Data</em>), qui remplacera l’actuel système MDC (<em>Modification Detection Code</em>) ;</li>
<li>quelques changements parmi les algorithmes « obligatoires » (MtI, <em>Mandatory-to-Implement</em>) — notamment, AES remplace 3DES comme algorithme symmétrique obligatoire ;</li>
<li>les additions du RFC 6637 (cryptographie ECC) sont incorporées, et les courbes Brainpool (<a href="https://tools.ietf.org/html/rfc5639">RFC 5639</a>) et Curve25519 (<a href="https://tools.ietf.org/html/rfc7748">RFC 7748</a>) sont ajoutées.</li>
</ul><p>Les changements concernant les algorithmes obligatoires ou recommandés sont somme toute assez évidents et n’appellent guère de commentaires. Nous aborderons le nouveau mode AEAD un peu plus loin, avec OpenPGP.js. Pour l’instant, attardons-nous sur le premier point, l’introduction du nouveau format de clef.</p>
<p>L’objectif principal du groupe de travail à cet égard était de se débarrasser de SHA-1. Cet algorithme de condensation est au cœur du RFC 4880, car il sert à calculer les empreintes des clefs au format V4. La résistance aux collisions n’est pas nécessaire dans ce cas de figure et les empreintes V4 ne sont pas menacées par les récentes attaques contre SHA-1, mais l’élimination de SHA-1 était jugée nécessaire pour ne pas donner l’impression que le standard OpenPGP devenait obsolète.<sup id="fnref1"><a href="#fn1">1</a></sup></p>
<p>Pour introduire un nouvel algorithme de calcul des empreintes tout en maintenant la compatibilité avec le standard et le code existant, le groupe de travail a convenu que la meilleure solution était de laisser le format V4 en l’état (toujours dépendant de SHA-1, donc) et <a href="https://mailarchive.ietf.org/arch/msg/openpgp/Zh1sqHZD8sVUfsW4OrMNx3dq4Ss">d’introduire un nouveau format V5</a>, dont les empreintes seraient calculées par un algorithme plus moderne.</p>
<p>Malheureusement, si tout le monde était d’accord sur le principe, le groupe de travail OpenPGP a perdu beaucoup de temps sur les détails, notamment sur le choix de l’algorithme « moderne » à utiliser. Il a même été envisagé de définir un format d’empreinte <em>flexible</em>, où le premier octet de l’empreinte indiquerait l’algorithme utilisé (ce qui aurait permis de changer plus facilement d’algorithme par la suite, sans avoir à créer un nouveau format de clef).</p>
<p>Les tergiversations du groupe autour de cette seule question ont fini par agacer l’IETF (qui n’aime pas trop les groupes de travail qui n’avancent pas) et, <a href="https://mailarchive.ietf.org/arch/msg/openpgp/Sd_ieUiZa31k0_ddS-2M8NEssy8">sous la pression d’une fermeture imminente du groupe</a>, les participants se sont finalement <a href="https://mailarchive.ietf.org/arch/msg/openpgp/tU_G_QNeUiy7G9F6iohU4nXS3yE">mis d’accord pour choisir SHA-256</a>, pour les raisons suivantes :</p>
<ul>
<li>les travaux réalisés dans le cadre de la <a href="https://fr.wikipedia.org/wiki/NIST_hash_function_competition">compétition SHA-3</a> ont montré que SHA-2 était beaucoup plus solide qu’on ne le pensait, réduisant l’intérêt de SHA-3 ;</li>
<li>SHA-256 est déjà pris en charge par toutes les implémentations existantes du standard (les signatures utilisant SHA-256 sont monnaies courantes depuis plusieurs années, c’est même l’algorithme de condensation par défaut de GnuPG depuis 2009), contrairement à SHA-3 — réutiliser SHA-256 réduira la charge des implémenteurs et facilitera la transition vers la nouvelle version du standard ;</li>
<li>SHA-256 peut être implémenté de manière efficace, même sur du matériel limité ;</li>
<li>une empreinte SHA-256 ne fait « que » 32 octets, ce qui est une augmentation raisonnable par rapport aux 20 octets d’une empreinte SHA-1 ; c’est important pour deux raisons :
<ul>
<li>ça évite de faire exploser la taille des signatures générées avec des clefs ECC (le problème ne se pose guère pour les signatures RSA, les clefs RSA modernes étant déjà beaucoup plus longues que le condensat de toute façon),</li>
<li>ça reste assez court pour que la représentation hexadécimale de l’empreinte (64 caractères) soit exploitable par des humains.</li>
</ul>
</li>
</ul><p>Malgré cette décision, l’IETF est restée sur son impression initiale et, considérant que le groupe de travail n’était pas assez actif, elle l’a <a href="https://mailarchive.ietf.org/arch/msg/openpgp/d6_ymZTQ6TtizxqVjjPk0AG1dLg">formellement fermé</a> quelques mois plus tard. Concrètement, ça ne change pas grand‐chose : la liste de discussion openpgp est restée ouverte et les travaux y continuent. L’existence formelle d’un groupe de travail n’est d’ailleurs pas une condition nécessaire à la publication d’un RFC.</p>
<h2 id="quelques-implémentations-dopenpgp">Quelques implémentations d’OpenPGP</h2>
<h3 id="pgp">PGP</h3>
<p>Impossible de ne pas dire quelques mots à propos de <em>PGP</em>, l’implémentation originale sans laquelle le standard n’existerait pas. Depuis la sortie de PGP 1.0 en 1991, ce logiciel a connu une histoire mouvementée et fascinante qui mériterait largement qu’on lui consacre un article à part entière, mais on se contentera ici d’en donner quelques faits marquants.</p>
<p>PGP a connu six éditeurs successifs :</p>
<ul>
<li>Philip Zimmermann (PRZ), lui‐même, à titre individuel, à partir de 1991 ;</li>
<li>ViaCrypt, à qui PRZ concède en 1993 le droit exclusif de vendre une version commerciale de PGP ;</li>
<li>
<em>PGP Inc.</em>, société fondée et dirigée par PRZ en 1996 à l’issue de ses démêlés judiciaires (on y revient dans un instant), qui rachète à ViaCrypt ses droits sur PGP ;</li>
<li>
<em>Network Associates Inc.</em> (NAI), qui acquiert PGP en décembre 1997 ; PRZ et son équipe de PGP Inc. deviennent employés de NAI ;</li>
<li>
<em>PGP Corp</em>, qui rachète PGP à Network Associates Inc. en 2002 ;</li>
<li>et finalement <em>Symantec</em>, qui rachète PGP Corp en 2010. PGP fait aujourd’hui partie de la gamme de produits <a href="https://www.symantec.com/en/ca/pgp/">Encryption Family</a> chez Symantec, même si le nom <em>PGP</em> lui‐même n’apparaît quasiment plus.</li>
</ul><p>La publication des premières versions de PGP a valu à Philip Zimmermann deux poursuites judiciaires distinctes.</p>
<p>L’une émane du gouvernement américain, en la forme du service des douanes de San José qui, à partir de septembre 1993 reproche à Philip Zimmermann, à ViaCrypt et à toute autre personne ou entité agissant pour le compte de PRZ, d’avoir enfreint les régulations américaines en matière d’exportations d’armement (<a href="https://en.wikipedia.org/wiki/ITAR">ITAR</a>), les logiciels de cryptographie étant considérées comme des munitions de guerre et PGP ayant rapidement fuité hors des frontières américaines, notamment via Usenet.</p>
<p>L’action du gouvernement américain s’inscrit dans le cadre de ce qu’on a appelé la <em>Crypto War</em>, une série d’efforts visant à limiter l’accès du public à la cryptographie « forte » et/ou à imposer l’introduction de portes dérobées au bénéfice des services gouvernementaux (entre autres exemples de ces efforts : la <a href="https://www.congress.gov/bill/102nd-congress/senate-bill/266">proposition de loi S.266</a> qui est justement celle qui décida PRZ à diffuser PGP, ou le <a href="https://en.wikipedia.org/wiki/Clipper_chip">projet Clipper</a>). On devrait maintenant parler de <em>Crypto War I</em>, puisque nous sommes actuellement en plein dans la <em>Crypto War II</em>.</p>
<p>Les charges contre Zimmermann ont finalement été <a href="http://openpgp.vie-privee.org/prz110196.txt">abruptement abandonnées</a> en janvier 1996. De l’avis des juristes qui se sont mobilisés pour PRZ, si l’affaire était allée jusqu’à un procès, l’issue n’aurait de toute façon pas fait un pli, les actes de PRZ (poster un code source sur les réseaux BBS) relevant indéniablement de la liberté d’expression protégée par le premier amendement de la constitution américaine.</p>
<p>La seconde poursuite contre PRZ émane de <em>RSA Data Security Inc.</em>, détenteur d’une partie des droits sur le brevet RSA, qui reproche à PRZ de diffuser un logiciel mettant en œuvre RSA sans disposer d’une licence l’y autorisant. PRZ avait cru se mettre à l’abri de ce genre de soucis en insérant dans la documentation de PGP 1.0 le <em>disclaimer</em> suivant :</p>
<blockquote>
<p><em>The RSA public key cryptosystem […] is patented by MIT (U.S. patent #4,405,829, issued 20 Sep 1983). A company called Public Key Partners (PKP) holds the exclusive commercial license to sell and sub‐license the RSA public key cryptosystem. […] The author of this software implementation of the RSA algorithm is providing this implementation for educational use only. Licensing this algorithm from PKP is the responsability of you, the user, not Philip Zimmermann, the author of this software implementation. The author assumes no liability for any breach of patent law resulting from the unlicensed use by the user of the underlying RSA algorithm used in this software.</em></p>
</blockquote>
<p>Mais RSA Data Security Inc. (principal membre de Public Key Partners) ne l’entendait pas de cette oreille et va contraindre PRZ à cesser de diffuser PGP. Zimmermann accepte, sachant que cela ne compromet en rien la diffusion de PGP : le logiciel est <em>déjà</em> en libre circulation sur Internet et interdire à PRZ de le diffuser n’empêchera pas ceux qui en ont déjà obtenu une copie de la diffuser à leur tour… Probablement l’un des premiers épisodes de la longue série « Le monde de la propriété intellectuelle découvre Internet ».</p>
<p>Pour les versions ultérieures de PGP, le problème du brevet RSA sera résolu de deux façons :</p>
<ul>
<li>PGP 2.4 est vendu par ViaCrypt, qui a acheté une licence pour RSA auprès de RSA Data Security Inc. ;</li>
<li>PGP 2.5 (et ultérieur) utilise <em>RSAREF</em>, une implémentation de RSA provenant du MIT. Ce dernier détenant toujours une partie des droits sur le brevet RSA, RSAREF n’est pas considérée comme violant ledit brevet. Cette position est initialement contestée par RSA Data Security Inc., qui n’insistera pas : s’attaquer au MIT n’est pas une mince affaire, contrairement à l’attaque d’un développeur isolé.</li>
</ul><p>Bien entendu, cela ne concerne que les versions de PGP diffusées sur le sol américain. Dans le reste du monde (où le brevet sur RSA n’est pas applicable), les versions <em>internationales</em> de PGP continuent à utiliser l’implémentation originale de PRZ au lieu de RSAREF, dont la licence interdit l’export hors des États‐Unis.</p>
<h3 id="gnupg">GnuPG</h3>
<p>GnuPG ou <em>GNU Privacy Guard</em> (parfois improprement appelé <em>gpg</em>, qui est en fait le nom du principal binaire exécutable du projet) est un logiciel libre de chiffrement et signature implémentant, entre autres, le standard OpenPGP. Le projet a été initié en 1997 par Werner Koch en réponse à un appel de Richard Stallman qui souhaitait que le projet GNU se dotât d’une alternative libre à PGP. C’est aujourd’hui l’implémentation libre de référence du standard OpenPGP.</p>
<p>Le projet existe en trois branches parallèles :</p>
<ul>
<li>la branche 1.4.x, largement désuète mais néanmoins activement maintenue par souci de compatibilité — c’est la seule branche aujourd’hui capable d’inter‐opérer encore avec PGP 2.x, les branches ultérieures ayant cessé de prendre en charge le RFC 1991 pour simplifier la base de code ;</li>
<li>la branche 2.2.x, la branche stable ;</li>
<li>la future branche 2.3.x, la branche de développement (qui n’a pas encore donné lieu à une publication).</li>
</ul><p>Les branches 2.0.x (ancienne branche stable) et 2.1.x (ancienne branche de développement) ne sont plus maintenues.</p>
<p>GnuPG est à la fois un outil directement utilisable en lui‐même (du moins pour les utilisateurs que la ligne de commande ne rebute pas), et un <em>back‐end</em> pour des logiciels en mode graphique tels que :</p>
<ul>
<li>
<a href="https://www.enigmail.net/">Enigmail</a>, un greffon pour le client de messagerie Thunderbird ;</li>
<li>
<a href="https://gnupg.org/software/gpa/index.html">GPA</a> (<em>GNU Privacy Assistant</em>), le frontal standard du projet ;</li>
<li>
<a href="https://wiki.gnome.org/Apps/Seahorse">Seahorse</a>, un outil de chiffrement et de gestion de clefs pour GNOME ;</li>
<li>
<a href="https://utils.kde.org/projects/kgpg/">KGpg</a>, l’équivalent pour KDE ;</li>
<li>etc.</li>
</ul><p>GnuPG sert aussi de <em>back‐end</em> à plusieurs bibliothèques ou modules dans divers langages de programmation :</p>
<ul>
<li>la bibliothèque <a href="https://gnupg.org/software/gpgme/index.html">GpgME</a>, en C ;</li>
<li>le module <a href="http://search.cpan.org/%7Ejred/Mail-GPG-1.0.12/lib/Mail/GPG.pm">Mail::GPG</a> de Perl ;</li>
<li>le module <a href="http://php.net/manual/en/ref.gnupg.php">GnuPG</a> de PHP ;</li>
<li>etc.</li>
</ul><p>L’omniprésence de GnuPG ne doit toutefois pas occulter qu’il ne s’agit pas de la seule implémentation libre du standard OpenPGP. Au fil du temps, des implémentations complètement indépendantes ont été développées.</p>
<h3 id="rnp-ex-openpgpsdk--netpgp">RNP (ex OpenPGPSDK / NetPGP)</h3>
<p>La plupart des fonctionnalités de GnuPG ne sont accessibles que <em>via</em> ses binaires exécutables (<code>gpg</code> pour tout ce qui concerne OpenPGP). Les fonctions cryptographiques de base sont regroupées dans une bibliothèque C à part, <em>libgcrypt</em>, qui est utilisée par d’autres projets indépendamment de GnuPG. Cependant, les fonctions de plus haut niveau sont implémentées directement dans les binaires exécutables, ce qui ne facilite pas forcément leur réutilisation dans d’autres projets.</p>
<p>La manière recommandée d’utiliser les fonctionnalités de GnuPG à partir d’un autre projet est d’invoquer le binaire <code>gpg</code>. Le programme dispose d’un mode non interactif spécialement conçu pour les cas où il est exécuté par un autre programme plutôt que par un utilisateur. La bibliothèque GpgME toute entière est en fait un <em>wrapper</em> autour de <code>gpg</code>, présentant aux développeurs des fonctions C « classiques » qui, pour la plupart, appellent <code>gpg</code> en arrière‐plan pour accomplir leur tâche.</p>
<p>Cette approche ne plaît pas à tout le monde et l’idée d’une « vraie » bibliothèque OpenPGP (c.‐à‐d., pas un <em>wrapper</em> autour de <code>gpg</code>) n’est pas nouvelle. La dernière incarnation de cette idée est <a href="https://github.com/riboseinc/rnp">RNP</a>, qui se présente comme « <em>a C library approach to OpenPGP</em> ».</p>
<p>RNP est développé par l’entreprise <a href="http://www.ribose.com/">Ribose</a> et est un <em>fork</em> de <a href="http://netpgp.com/">NetPGP</a>, une implémentation d’OpenPGP <a href="http://mail-index.netbsd.org/tech-security/2009/05/25/msg000231.html">initiée en 2009</a> par des développeurs de NetBSD. NetPGP lui‐même est bâti sur <em>OpenPGP-SDK</em>, une bibliothèque OpenPGP <a href="https://www.ietf.org/mail-archive/web/openpgp/current/msg00469.html">publiée quelques mois auparavant</a> par Ben Laurie et Rachel Willmer.</p>
<p>Aujourd’hui, tant OpenPGP-SDK que NetPGP sont au point mort. Le <a href="https://github.com/public/OpenPGP-SDK/">site officiel d’OpenPGP-SDK</a> ne répond plus, et bien qu’une copie des sources soit toujours disponible <a href="https://github.com/public/OpenPGP-SDK">sur GitHub</a> et dans le CVS de NetBSD, elles n’ont plus été modifiées depuis 2011. La dernière version de NetPGP remonte à 2014 et le CVS ne témoigne d’aucune activité au cours des cinq dernières années. L’implémentation est pourtant loin d’être complète, des fonctionnalités aussi élémentaires que le chiffrement pour plusieurs destinataires étant toujours absentes. Il semble assez évident que le projet est abandonné, en dépit de la <a href="http://netpgp.com/faq.html">FAQ</a> qui prétend qu’il est toujours « activement maintenu et développé » — mais la FAQ elle‐même n’a pas été mise à jour depuis 2010…</p>
<p>Le développement de RNP est, lui, bien actif. Depuis son démarrage fin 2016, le projet comble progressivement les lacunes de son prédécesseur. Cependant, il n’est pas encore pleinement compatible avec le standard, n’a pas été audité et souffre de quelques bogues récurrents. Le fondateur de Ribose, Ronald Tse, est activement impliqué dans l’élaboration du RFC 4880bis au sein du groupe de travail OpenPGP. Dans l’ensemble, RNP est certainement un projet à suivre.</p>
<h3 id="autres-implémentations">Autres implémentations</h3>
<p>Voici quelques autres projets implémentant le standard OpenPGP ; les projets explicitement ou manifestement abandonnés ne sont pas inclus :</p>
<ul>
<li>
<a href="https://github.com/das-labor/neopg">NeoPG</a>, un <em>fork</em> de GnuPG converti en C++11 et utilisant <a href="https://botan.randombit.net/">Botan</a> plutôt que libgcrypt comme bibliothèque cryptographique ; le projet souhaite notamment revenir à l’architecture monolithique de GnuPG 1.x (suppression des démons de GnuPG 2.x) et globalement à « dégrossir » le code (de nombreuses fonctionnalités introduites dans les versions modernes de GnuPG ont déjà été supprimées) ;</li>
<li>
<a href="https://github.com/singpolyma/openpgp-php">OpenPGP-PHP</a>, une implémentation en pur PHP, à ne pas confondre avec <a href="https://github.com/php-gnupg/php-gnupg">php-gnupg</a> qui est une bibliothèque de liaison (<em>binding</em>) de GpgME pour PHP ;</li>
<li>
<a href="https://hackage.haskell.org/package/hOpenPGP">hOpenPGP</a>, une implémentation en Haskell ;</li>
<li>
<a href="https://bouncycastle.org/">Bouncy Castle</a>, une bibliothèque cryptographique disponible en Java et en C#, fournissant (entre beaucoup d’autres choses) une implémentation du RFC 4880 ;</li>
<li>
<a href="https://github.com/krzyzanowskim/ObjectivePGP">ObjectivePGP</a>, une implémentation en Objective C pour macOS et iOS, <a href="https://github.com/krzyzanowskim/ObjectivePGP/blob/master/LICENSE.txt">non libre</a> qui sert notamment de base à <a href="http://privacyapp.io/">Privacy</a>, une messagerie PGP pour iOS (également non libre, apparemment) ; on appréciera les ambitions du développeur : <em>I believe I can revolutionize how PGP is used</em> ;</li>
<li>
<a href="https://github.com/kryptco/swift-pgp/">Swift-PGP</a>, une implémentation en Swift encore très rudimentaire (en particulier, elle ne prend pas encore en charge les opérations de chiffrement, seulement les opérations de signature) ; licence « non encore décidée » (donc, non libre) ;</li>
<li>
<a href="https://www.cs.auckland.ac.nz/%7Epgut001/cryptlib/index.html">Cryptlib</a>, une bibliothèque cryptographique en C par Peter Gutmann fournissant, entre autres, une implémentation OpenPGP ;</li>
<li>
<a href="https://github.com/btrott/Crypt-OpenPGP">Crypt::OpenPGP</a>, une implémentation en Perl.</li>
</ul><h2 id="openpgpjs">OpenPGP.js</h2>
<p>La bibliothèque OpenPGP.js est issue et inspirée de <a href="https://github.com/openpgpjs/openpgpjs#resources">plusieurs projets défunts</a>. Le dénominateur commun de ces derniers était l’objectif d’implémenter tout ou partie du standard OpenPGP en JavaScript pour faire du chiffrement côté client dans les webmails. Parmi ces projets abandonnés, citons <a href="https://web.archive.org/web/20120817081840/http://gpg4browsers.recurity.com:80/">GPG4Browsers</a>.</p>
<p>OpenPGP.js était dirigé par <a href="https://tankredhase.com/about/">Tankred Hase</a>, cofondateur de <a href="https://whiteout.io/">Whiteout</a>. Au cours de l’été 2016, il a été <a href="https://github.com/openpgpjs/openpgpjs/issues/480">remplacé par Bart Butler</a>, directeur technique de <a href="https://protonmail.com/about">Proton Technologies AG</a>, l’entreprise derrière ProtonMail. Outre ce webmail, la bibliothèque est utilisée par des projets tels que <a href="https://hoodiecrow.com/">Hoodiecrow</a>, <a href="https://www.mailvelope.com/en">Mailvelope</a>, la plate‐forme <a href="https://encrypt.to/"><em>encrypt.to</em></a> ou l’extension <a href="https://github.com/JamesCullum/PGP-Anywhere">PGP-Anywhere</a> pour le navigateur Google Chrome.</p>
<p>En termes de sécurité, l’utilisation d’un langage interprété comme JavaScript n’est pas anodine. En effet, pour un programme compilé tel que GnuPG, l’exécution est censée être sure si le système hôte n’est pas compromis. Dans le cas d’OpenPGP.js, il faut également que le moteur JavaScript — qui réside en général dans le navigateur — ne soit pas compromis. La surface d’attaque est ainsi plus grande.</p>
<h3 id="loption-openpgpconfigaead_protect-anatomie-dune-mauvaise-idée">L’option openpgp.config.aead_protect, anatomie d’une mauvaise idée</h3>
<p>Une spécificité d’OpenPGP.js que ses développeurs prennent soin de mettre en avant est la possibilité d’utiliser AES-GCM pour le chiffrement symétrique, qui « rend(rait) le chiffrement trente fois plus rapide » (<em>a priori</em>, comparé à AES-CFB, bien que ce ne soit pas explicite) :</p>
<blockquote>
<p>The library implements the <a href="https://tools.ietf.org/html/draft-ford-openpgp-format-00">IETF proposal</a> for authenticated encryption using native AES-GCM. This makes symmetric encryption about 30× faster on supported platforms. Since the specification is not finalized and other OpenPGP implementations haven’t adopted it yet, the feature is currently behind a flag. You can activate it by setting <code>openpgp.config.aead_protect = true</code>. <em>Note: activating this setting can break compatibility with other OpenPGP implementations, so be careful if that’s one of your requirements.</em></p>
</blockquote>
<p>Cela semble alléchant, mais utiliser cette fonctionnalité revient en fait à se tirer une balle dans le pied et il est important de comprendre pourquoi. C’est l’objet de cette section. Cela va également nous fournir l’occasion de revenir sur l’une des principales nouveautés de la prochaine version du standard OpenPGP : le chiffrement authentifié.</p>
<hr><p><strong>TL;DR:</strong> La « proposition IETF » mentionnée est une version préliminaire qui n’a aucune chance d’être intégrée telle quelle dans le standard, le groupe de travail OpenPGP ayant depuis formulé une proposition différente. Conséquemment, elle ne sera jamais prise en charge par aucune autre implémentation d’OpenPGP. Si vous utilisez cette « fonctionnalité », vos messages ne seront <strong>pas</strong> lisibles par d’autres implémentations d’OpenPGP (c’est une <em>certitude</em>, pas seulement une <em>possibilité</em> comme le laisse entendre l’avertissement ci‐dessus) et, pire encore, il est probable qu’ils ne soient même pas lisibles avec les versions <em>futures</em> d’OpenPGP.js. <em>Laissez <code>openpgp.config.aead_protect</code> à <code>false</code> !</em></p>
<hr><h4 id="openpgp-et-lintégrité-des-messages-chiffrés">OpenPGP et l’intégrité des messages chiffrés</h4>
<p>Une des garanties que l’on attend d’un format comme OpenPGP est l’assurance qu’un message chiffré n’a pas été modifié en cours de route (c’est <em>l’intégrité</em> du message). La <em>signature</em> du message est un moyen d’offrir cette garantie (toute modification du message invalidant la signature), mais elle n’est pas toujours désirable (notamment parce que la signature lie le message à son émetteur/signataire, ce qui n’est pas forcément dans l’intérêt de ce dernier — pensez à un lanceur d’alerte par exemple).</p>
<p>OpenPGP offre donc, indépendamment des signatures, un système de vérification de l’intégrité d’un message chiffré, le <em>Modification Detection Code</em> (MDC ci‐après), dont le principe est le suivant : lors de la création d’un message chiffré, l’émetteur calcule un condensat cryptographique du texte clair, l’ajoute à la fin du texte, et c’est l’ensemble (texte clair, condensat) qui est alors chiffré. À la réception, le destinataire déchiffre le message, calcule à son tour un condensat sur le texte clair et le compare au condensat reçu : si les deux divergent, le message a été modifié.</p>
<p>Ce principe, connu sous le nom générique de <em>MAC-then-Encrypt</em> (bien que ce terme soit impropre dans le cas du MDC d’OpenPGP, le MDC n’étant <em>pas</em> un <a href="https://en.wikipedia.org/wiki/Message_authentication_code">MAC</a>), n’a plus les faveurs des cryptographes de nos jours. Son problème fondamental est qu’il impose, du côté du destinataire, de déchiffrer le message <em>avant</em> de pouvoir vérifier qu’il n’a pas été modifié. Entre autres conséquences, cela laisse la porte entr’ouverte à de potentielles attaques « à textes chiffrés choisis » (<em>chosen‐ciphertext attacks</em>) comme celle de <a href="https://www.schneier.com/academic/archives/2002/01/implementation_of_ch.html">Jallad, Katz et Schneier (2002)</a>. Il est généralement admis aujourd’hui qu’il faut privilégier le principe <em>Encrypt‐then‐MAC</em> (calculer le MAC sur le texte chiffré, permettant au destinataire de vérifier l’intégrité avant toute tentative de déchiffrement) ou, mieux, un <a href="https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation">mode d’opération</a> combinant chiffrement et authentification (<em>Authenticated Encryption with Associated Data</em> ou AEAD).</p>
<h4 id="les-propositions-du-groupe-de-travail-openpgp">Les propositions du groupe de travail OpenPGP</h4>
<p>Prenant acte du consensus des cryptographes en faveur d’AEAD, le groupe de travail OpenPGP à l’IETF a commencé à étudier la question lors de la réunion <a href="https://www.ietf.org/proceedings/93/index.html">IETF ’93</a> en juillet 2015. Et, quelques mois plus tard, Bryan Ford publiait <a href="https://tools.ietf.org/html/draft-ford-openpgp-format-00">un brouillon</a> proposant la création d’un nouveau type de paquet spécialement conçu pour l’utilisation d’algorithmes permettant le chiffrement authentifié. Dans ce brouillon initial, un <em>AEAD Encrypted Data Packet</em> est identifié par le code <code>20</code> et est formé par la simple concaténation du vecteur d’initialisation, du texte chiffré proprement dit et du code d’authentification.</p>
<p>L’objectif du brouillon de Bryan Ford était de servir de base de discussion pour le groupe de travail OpenPGP, ce qui fut notamment le cas lors de la réunion <a href="https://www.ietf.org/proceedings/94/slides/slides-94-openpgp-2.pdf">IETF ’94</a>. Mais il n’a jamais été prévu qu’il aille plus loin que ça, et le brouillon a expiré normalement sans jamais devenir un RFC. Les idées qu’il a suscitées devant ensuite trouver leur place dans le futur RFC 4880bis, dont le chantier venait de commencer.</p>
<p>Par la suite, Brian Carlson a formulé une <a href="https://mailarchive.ietf.org/arch/msg/openpgp/VMU9DimE10coNaAxnqs101VT5eA">nouvelle proposition</a> qui a été intégrée dans le brouillon actuel du RFC 4880bis. Dans sa forme actuelle, elle reprend l’idée de Bryan Ford de créer un nouveau type de paquet (toujours avec le code <code>20</code>), mais avec une composition différente :</p>
<ul>
<li>un octet représentant le numéro de version du format de paquet (pour pouvoir faire évoluer le format si nécessaire) ;</li>
<li>un octet indiquant l’algorithme symétrique avec lequel les données du paquet sont chiffrées (AES128, AES192, Camellia, etc.) ;</li>
<li>un octet indiquant le mode AEAD choisi (<em>cf.</em> ci‐dessous) ;</li>
<li>le vecteur d’initialisation ;</li>
<li>le texte chiffré proprement dit ;</li>
<li>le code final d’authentification.</li>
</ul><p>Deux modes AEAD sont pour l’instant retenus : EAX et <a href="https://tools.ietf.org/html/rfc7253">OCB</a>. Toutefois, OCB fait l’objet de brevets aux États‐Unis (<a href="http://web.cs.ucdavis.edu/%7Erogaway/ocb/patent-rogaway-3.pdf">7,949,129</a> et <a href="http://web.cs.ucdavis.edu/%7Erogaway/ocb/patent-rogaway-4.pdf">8,321,675</a>), et son maintien dans le RFC final n’est pas garanti, tous les membres du groupe de travail OpenPGP n’étant pas favorables à l’inclusion d’un algorithme breveté. À noter que Philip Rogaway, auteur d’OCB et détenteur des brevets en question, accorde une <a href="http://web.cs.ucdavis.edu/%7Erogaway/ocb/license1.pdf">licence d’utilisation</a> à tout projet sous licence libre, ce qui devrait <em>a priori</em> lever tout obstacle à l’implémentation d’OCB dans GnuPG ou OpenPGP.js — mais le groupe de travail pense aussi aux implémentations propriétaires du standard, comme Symantec PGP par exemple.</p>
<p>Aujourd’hui, à l’incertitude sur le sort du mode OCB près, la forme actuelle du <em>AEAD Encrypted Data Packet</em> semble faire consensus au sein du groupe de travail et elle devrait probablement se retrouver sans trop de modifications dans la version finale du RFC 4880bis.</p>
<p>Le système MDC actuel, de son côté, sera maintenu pour des raisons de compatibilité, mais il n’est pas prévu de le faire évoluer. L’idée est que les implémentations cessent progressivement d’utiliser le mode de chiffrement actuel (avec son système MDC) et basculent vers le chiffrement AEAD qui, à terme, devrait devenir ubiquitaire.</p>
<h4 id="et-openpgpjs-là-dedans">Et OpenPGP.js là-dedans ?</h4>
<p>Début 2016, les développeurs d’OpenPGP.js ont pris connaissance du brouillon initial de Bryan Ford et ont pris l’initiative de l’implémenter, ainsi qu’<a href="https://lists.gnupg.org/pipermail/gnupg-users/2016-March/055629.html">ils l’ont signalé</a> sur la liste de discussion <em>gnupg-devel</em> :</p>
<blockquote>
<p><em>For the sake of experimenting and to gain insight on the IETF draft, OpenPGP.js will go ahead and merge the AEAD pull request based on the current AES-GCM proposal. The feature will be hidden behind a flag and disabled by default. But it will allow applications that do not require interoperability to opt‐in and experiment with the security/performance benefits.</em></p>
</blockquote>
<p>Il n’y a évidemment aucun mal à expérimenter avec les brouillons IETF. C’est même, entre autres, à ça qu’ils servent. Mais l’approche d’OpenPGP.js est ici problématique à mon sens, pour plusieurs raisons :</p>
<ul>
<li>il y a un double discours de la part des développeurs d’OpenPGP.js : d’un côté (dans les discussions avec GnuPG) c’est une « expérimentation » visant à améliorer la proposition de standard, de l’autre (dans le <em>README</em> du projet) c’est une fonctionnalité offrant un gain sensible de performances (« 30 fois plus rapide ») ;</li>
<li>initialement la fonctionnalité était <em>activée par défaut</em>, jusqu’à ce qu’un développeur <a href="https://github.com/openpgpjs/openpgpjs/pull/430#issuecomment-200753143">réalise</a> que les gens s’attendent probablement à ce qu’une bibliothèque appelée <em>OpenPGP.js</em> soit par défaut compatible avec le standard <em>OpenPGP</em> ;</li>
<li>il a fallu un an avant qu’un avertissement ne soit ajouté au <em>README</em> du projet pour prévenir que <code>aead_protect</code> « peut casser la compatibilité avec d’autres implémentations », alors même qu’il est <em>certain</em> qu’un message chiffré par OpenPGP.js avec cette fonctionnalité activée est et sera toujours illisible par toutes les autres implémentations ;</li>
<li>le standard OpenPGP prévoit des codes spécifiques pour les paquets non standard (codes <code>60</code> à <code>63</code>, réservées aux usages « privés ou expérimentaux ») ; indépendamment du réel statut de la fonctionnalité <code>aead_protect</code> (destinée à expérimenter et améliorer le brouillon IETF, ou destinée aux utilisateurs désireux de gagner en performances et n’ayant pas besoin de compatibilité avec les autres implémentations), les développeurs auraient dû utiliser un de ces codes au lieu de décider unilatéralement d’utiliser le code <code>20</code> pour le nouveau <code>AEAD Encrypted Data Packet</code>.</li>
</ul><p>Ce dernier point va immanquablement poser un gros problème dans un futur proche. La version actuelle du brouillon IETF pour le RFC 4880bis décrit un <em>AEAD Encrypted Data Packet</em> qui est complètement différent de celui actuellement utilisé par OpenPGP.js (puisque les développeurs d’OpenPGP.js se sont basés sur des travaux préliminaires), alors qu’ils utilisent le même code. À la sortie du RFC 4880bis, l’implémentation d’OpenPGP.js va donc devoir être mise à jour pour se conformer à la version finale du standard (<a href="https://github.com/openpgpjs/openpgpjs/issues/627">c’est déjà noté par les développeurs</a>)… et de fait casser la compatibilité avec leur implémentation actuelle !</p>
<h3 id="les-nouveautés-dopenpgpjs-304">Les nouveautés d’OpenPGP.js 3.0.4</h3>
<p>Les <a href="https://github.com/openpgpjs/openpgpjs/releases/">notes de version</a> fournissent un descriptif complet, retenons tout de même les points suivants.</p>
<h4 id="prise-en-charge-des-courbes-elliptiques">Prise en charge des courbes elliptiques</h4>
<p>La plus importante est la prise en charge de la cryptographie à base de courbes elliptiques (ECC, <em>Elliptic Curve Cryptography</em>). Concrètement, il est désormais possible de générer et utiliser des clefs publiques ECDSA (pour la signature) et ECDH (pour le chiffrement). L’avantage est une réduction significative de la taille des clefs, par rapports aux clefs RSA, DSA ou ElGamal. Les courbes prises en charge sont celles du <a href="https://fr.wikipedia.org/wiki/National_Institute_of_Standards_and_Technology" title="National Institute of Standards and Technology">NIST</a>, les courbes Brainpool, et la <a href="https://fr.wikipedia.org/wiki/Curve25519">courbe 25519</a>.</p>
<p>Attention à l’interopérabilité si vous utilisez de telles clefs. D’une part, pour l’instant, seules les courbes du NIST font officiellement partie du standard OpenPGP (depuis le RFC 6637), les autres courbes sont ajoutées par le RFC 4880bis, qui n’est encore qu’un brouillon (cela dit, il y a peu de chances que les identifiants associés à ces courbes changent d’ici la version finale). D’autre part, GnuPG ne prend en charge la cryptographie elliptique que depuis sa version 2.1, certes sortie il y a maintenant plus de trois ans, mais les versions 1.x et 2.0.x font encore de la résistance.</p>
<h4 id="masquage-de-lidentité-du-destinataire">Masquage de l’identité du destinataire</h4>
<p>L’autre nouveauté — beaucoup plus anecdotique — se cache derrière le nom <em>wildcard key ID</em> et consiste en la possibilité de masquer l’identité du destinataire d’un message chiffré. C’est en fait l’équivalent des options <code>--throw-keyids</code> ou <code>--hidden-recipient</code> de GnuPG.</p>
<p>Comme évoqué plus haut, sous sa forme la plus simple un message chiffré se présente sous la forme de deux paquets : un premier paquet contenant une clef de session <em>chiffrée avec la clef publique du destinataire</em>, suivi d’un paquet contenant le corps du message chiffré avec la clef de session. Dans le premier paquet, on trouve normalement l’identifiant de la clef publique du destinataire, ce qui permet au logiciel du destinataire de savoir immédiatement quelle clef utiliser pour déchiffrer la clef de session. Mais cela a aussi pour effet de révéler indirectement l’identité dudit destinataire (il suffit de savoir à qui appartient la clef référencée).</p>
<p>Utiliser une <em>wildcard key ID</em> consiste à ne pas inclure l’identifiant de la clef du destinataire dans le premier paquet (ou, plus précisément, à inclure un identifiant factice composé uniquement de zéros). À la réception d’un tel message, le logiciel du destinataire va simplement essayer successivement toutes les clefs privées à sa disposition, jusqu’à trouver celle qui permet de déchiffrer la clef de session. Ce n’est pas supposé prendre beaucoup de temps, dans la mesure où un utilisateur n’a typiquement qu’une seule clef de chiffrement de toute façon (plus, éventuellement, quelques anciennes clefs arrivées à expiration qu’il garde pour déchiffrer des vieux messages).</p>
<p>Attention toutefois, dans le cadre du courrier électronique, utiliser une <em>wildcard key ID</em> ne change rien au fait qu’OpenPGP ne protège que le <em>corps</em> du message et que toutes les métadonnées du courrier électronique (dont l’en‐tête <code>To:</code> et la commande SMTP <code>RCPT TO</code>) sont toujours en clair (sauf à utiliser TLS). Le gain en confidentialité apporté par cette fonctionnalité est donc très relatif.</p>
<h4 id="les-changements-sous-le-capot">Les changements sous le capot</h4>
<p>Au‐delà des nouvelles fonctionnalités, OpenPGP.js a fait l’objet d’un <em>réusinage</em> assez conséquent pour cette version 3.0.0. Notamment, plusieurs des bibliothèques sur lesquelles s’appuient OpenPGP.js ont changé :</p>
<ul>
<li>les opérations sur grands nombres sont désormais confiées à <a href="https://github.com/indutny/bn.js/"><em>bn.js</em></a> au lieu de <a href="http://www-cs-students.stanford.edu/%7Etjw/jsbn/"><em>jsbn</em></a> ;</li>
<li>la (dé)compression Zlib utilise désormais soit le module <a href="https://nodejs.org/api/zlib.html">Zlib fourni avec Node.js</a>, soit la bibliothèque <a href="https://github.com/nodeca/pako"><em>pako</em></a>, au lieu de <a href="https://github.com/imaya/zlib.js/"><em>zlibjs</em></a> ;</li>
<li>la (dé)compression BZip2 utilise désormais une version <a href="https://github.com/openpgpjs/compressjs">dérivée</a> de <a href="https://github.com/cscott/compressjs"><em>compressjs</em></a>.</li>
</ul><p>Le code JavaScript utilise désormais <a href="https://fr.wikipedia.org/wiki/ECMAScript#ECMAScript_Edition_6_(ES6)">ECMAScript 6</a> pour la déclaration des variables et ECMAScript 7 pour le code asynchrone. La compatibilité avec les anciens navigateurs étant maintenue grâce à <a href="https://babeljs.io/">Babel</a>. Par ailleurs, la cohérence du style du code est maintenant vérifiée avec <a href="https://eslint.org/">ESLint</a>.</p>
<div class="footnotes">
<hr>
<ol>
<li id="fn1">
<p><a href="https://mailarchive.ietf.org/arch/msg/openpgp/hN2Ytrv7C6kZfSy79Sy7VXDg2-Y">Robert J. Hansen</a>: « Removing [SHA-1] cuts down on the amount of (wholly inappropriate) fearmongering that gets thrown aroung by the ignorant whenever SHA-1 is mentioned. OpenPGP adoption is slow enough already; continued use of SHA-1, even where it’s safe, seems contraindicated. » <a href="#fnref1">↩</a></p>
</li>
</ol>
</div></div><div><a href="https://linuxfr.org/news/gnupg-openpgp-js-cie-quoi-de-neuf.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/113935/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/gnupg-openpgp-js-cie-quoi-de-neuf#comments">ouvrir dans le navigateur</a>
</p>
AnonymeDavy DefaudgouttegdBenoît SibaudNicolas Casanovabolikahultpalm123https://linuxfr.org/nodes/113935/comments.atomtag:linuxfr.org,2005:News/381472017-08-22T11:22:07+02:002017-08-26T18:54:02+02:00Nouvelles versions logicielles du projet GNU juin et juillet 2017Licence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<div><p>Le projet GNU publie tous les mois une liste de versions logicielles publiées. Jetons‐y un coup d’œil pour découvrir de nouveaux logiciels inconnus (de moi), des infâmes bogues disparus ou les promesses de solutions à tous nos besoins : soit des dizaines de nouvelles versions annoncées allant de la corrective mineure à la version attendue depuis des années ; et l’on va donc parler de <code>acct</code>, <code>auctex</code>, <code>automake</code>, <code>binutils</code>, <code>cgicc</code>, <code>dr-geo</code>, <code>freeipmi</code>, <code>gama</code>, <code>gcc</code>, <code>gdb</code>, <code>glpk</code>, <code>gnuastro</code>, <code>gnucash</code>, <code>gnuhealth</code>, <code>gnuhealth-control</code>, <code>gnupg</code>, <code>gnutls</code>, <code>grep</code>, <code>gsl</code>, <code>guile-cv</code>, <code>guile-gnome</code>, <code>libextractor</code>, <code>libffcall</code>, <code>libgcrypt</code>, <code>libidn2</code>, <code>libmicrohttpd</code>, <code>libtasn1</code>, <code>linux-libre</code>, <code>moe</code>, <code>motti</code>, <code>nano</code>, <code>parallel</code>, <code>screen</code>, <code>taler</code>, <code>texinfo</code>, <code>tramp</code> et <code>unifont</code>.</p></div><ul><li>lien nᵒ 1 : <a title="http://www.fsf.org/blogs/community/twenty-one-new-gnu-releases-in-the-month-of-july" hreflang="en" href="https://linuxfr.org/redirect/100444">Twenty‐one new GNU releases in the month of July </a></li><li>lien nᵒ 2 : <a title="http://www.fsf.org/blogs/community/twenty-three-new-gnu-releases-in-the-month-of-june-1" hreflang="en" href="https://linuxfr.org/redirect/100445">Twenty‐three new GNU releases in the month of June </a></li><li>lien nᵒ 3 : <a title="https://linuxfr.org/news/nouvelles-versions-logicielles-du-projet-gnu-avril-et-mai-2017/" hreflang="fr" href="https://linuxfr.org/redirect/100446">Nouvelles versions logicielles du projet GNU avril et mai 2017</a></li></ul><div><h2 class="sommaire">Sommaire</h2>
<ul class="toc">
<li>
<a href="#acct-664-juillet"></a><a href="https://www.gnu.org/software/acct/">acct-6.6.4</a> (juillet)</li>
<li>
<a href="#auctex-1191-juillet"></a><a href="https://www.gnu.org/software/auctex/">auctex-11.91</a> (juillet)</li>
<li>
<a href="#automake-1151-juin"></a><a href="https://www.gnu.org/software/automake/">automake-1.15.1</a> (juin)</li>
<li>
<a href="#binutils-229-juillet"></a><a href="https://www.gnu.org/software/binutils/">binutils-2.29</a> (juillet)</li>
<li>
<a href="#cgicc-3218-et-3219-juin-et-juillet"></a><a href="https://www.gnu.org/software/cgicc/">cgicc-3.2.18 et 3.2.19</a> (juin et juillet)</li>
<li>
<a href="#dr-geo-1707-juin"></a><a href="https://www.gnu.org/software/dr-geo/">dr-geo-17.07</a> (juin)</li>
<li>
<a href="#freeipmi-156-juillet"></a><a href="https://www.gnu.org/software/freeipmi/">freeipmi-1.5.6</a> (juillet)</li>
<li>
<a href="#gama-119-juillet"></a><a href="https://www.gnu.org/software/gama/">gama-1.19</a> (juillet)</li>
<li>
<a href="#gcc-640-juillet"></a><a href="https://www.gnu.org/software/gcc/">gcc-6.4.0</a> (juillet)</li>
<li>
<a href="#gdb-80-juin"></a><a href="https://www.gnu.org/software/gdb/">gdb-8.0</a> (juin)</li>
<li>
<a href="#glpk-462-et-463-juinetjuillet"></a><a href="https://www.gnu.org/software/glpk/">glpk-4.62 et 4.63</a> (juin et juillet)</li>
<li>
<a href="#gnuastro-03-juin"></a><a href="https://www.gnu.org/software/gnuastro/">gnuastro-0.3</a> (juin)</li>
<li>
<a href="#gnucash-2617-juillet"></a><a href="https://www.gnu.org/software/gnucash/">gnucash-2.6.17</a> (juillet)</li>
<li>
<a href="#gnuhealth-320-et-321-juillet"></a><a href="http://health.gnu.org/">gnuhealth-3.2.0 et 3.2.1</a> (juillet)</li>
<li>
<a href="#gnupg-2122-juillet"></a><a href="https://gnupg.org/">gnupg-2.1.22</a> (juillet)</li>
<li>
<a href="#gnutls-3513-et-3514-juinetjuillet"></a><a href="https://www.gnu.org/software/gnutls/">gnutls-3.5.13 et 3.5.14</a> (juin et juillet)</li>
<li>
<a href="#grep-31-juillet"></a><a href="https://www.gnu.org/software/grep/">grep-3.1</a> (juillet)</li>
<li>
<a href="#gsl-24-juin"></a><a href="https://www.gnu.org/software/gsl/">gsl-2.4</a> (juin)</li>
<li>
<a href="#guile-cv-015-juillet"></a><a href="https://www.gnu.org/software/guile-cv/">guile-cv-0.1.5</a> (juillet)</li>
<li>
<a href="#guile-gnome-2165-juin"></a><a href="https://www.gnu.org/software/guile-gnome/">guile-gnome-2.16.5</a> (juin)</li>
<li>
<a href="#libextractor-14-juin"></a><a href="https://www.gnu.org/software/libextractor/">libextractor-1.4</a> (juin)</li>
<li>
<a href="#libffcall-113-juin"></a><a href="https://www.gnu.org/software/libffcall/">libffcall-1.13</a> (juin)</li>
<li>
<a href="#libgcrypt-177-et-180-juin-et-juillet"></a><a href="https://gnupg.org/software/libgcrypt/index.html">libgcrypt-1.7.7 et 1.8.0</a> (juin et juillet)</li>
<li>
<a href="#libidn2-203-juillet"></a><a href="https://www.gnu.org/software/libidn/#libidn2">libidn2-2.0.3</a> (juillet)</li>
<li>
<a href="#libmicrohttpd-0955-juin"></a><a href="https://www.gnu.org/software/libmicrohttpd/">libmicrohttpd-0.9.55</a> (juin)</li>
<li>
<a href="#libtasn1-412-juin"></a><a href="https://www.gnu.org/software/libtasn1/">libtasn1-4.12</a> (juin)</li>
<li>
<a href="#linux-libre-4117-gnu-et-4123-gnu-juinetjuillet"></a><a href="http://www.fsfla.org/ikiwiki/selibre/linux-libre/">linux-libre-4.11.7-gnu et 4.12.3-gnu</a> (juin et juillet)</li>
<li>
<a href="#moe-19-juillet"></a><a href="https://www.gnu.org/software/moe/">moe-1.9</a> (juillet)</li>
<li>
<a href="#motti-311-juin"></a><a href="https://www.gnu.org/software/motti/">motti-3.1.1</a> (juin)</li>
<li>
<a href="#nano-285-et-286-juinetjuillet"></a><a href="https://www.nano-editor.org/news.php">nano-2.8.5 et 2.8.6</a> (juin et juillet)</li>
<li>
<a href="#parallel-20170622-et-20170722-juin-et-juillet"></a><a href="https://www.gnu.org/software/parallel/">parallel-20170622 et 20170722</a> (juin et juillet)</li>
<li>
<a href="#screen-460-et-461-juin-et-juillet"></a><a href="https://www.gnu.org/software/screen/">screen-4.6.0 et 4.6.1</a> (juin et juillet)</li>
<li>
<a href="#taler-030-juin"></a><a href="https://www.gnu.org/software/taler/">taler-0.3.0</a> (juin)</li>
<li>
<a href="#texinfo-64-juin"></a><a href="https://www.gnu.org/software/texinfo/">texinfo-6.4</a> (juin)</li>
<li>
<a href="#tramp-232-juillet"></a><a href="https://www.gnu.org/software/tramp/">tramp-2.3.2</a> (juillet)</li>
<li>
<a href="#unifont-10001-%C3%A0-10005-juinetjuillet"></a><a href="https://www.gnu.org/software/unifont/">unifont-10.0.01 à 10.0.05</a> (juin et juillet)</li>
<li><a href="#conclusion">Conclusion</a></li>
</ul><h2 id="acct-664-juillet">
<a href="https://www.gnu.org/software/acct/">acct-6.6.4</a> (juillet)</h2>
<p>Il s’agit d’une mise à jour mineure de cet outil d’enregistrement des actions sur le système (nom d’utilisateur et processus), pour ajouter <code>--pid</code> sur <code>lastcomm</code>.</p>
<h2 id="auctex-1191-juillet">
<a href="https://www.gnu.org/software/auctex/">auctex-11.91</a> (juillet)</h2>
<p>Ce logiciel extensible permet d’écrire et de formater des fichiers TeX dans GNU Emacs et XEmacs (en gérant de nombreux paquets de macro TeX, dont AMS-TeX, LaTeX, Texinfo, ConTeXt et docTeX [dtx]). Cette version amène un nouveau logo, la gestion de <code>upmendex</code>, l’entrée <code>Glossaries</code> pour générer les glossaires, une amélioration de la <em>fontification</em> des symboles de contrôle, de verbatim et de maths, une nouvelle option <code>TeX-ispell-verb-delimiters</code>, l’ajout et l’analyse de labels, des corrections et des nouveaux paquets LaTeX pris en charge.</p>
<h2 id="automake-1151-juin">
<a href="https://www.gnu.org/software/automake/">automake-1.15.1</a> (juin)</h2>
<p>Cet outil de génération des fichiers <em>Makefile</em> portables (utilisables par <em>make</em> pour compiler des programmes) avait vu sa version précédente 1.15 sortir en janvier 2015. La nouvelle version amène des corrections de bogues (suppression d’avertissements avec Perl 5.22+ et d’erreurs avec Perl 5.26+, suppression de la variable <code>GZIP</code>) et prise en charge de la version Windows du compilateur C d’Intel (icl).</p>
<h2 id="binutils-229-juillet">
<a href="https://www.gnu.org/software/binutils/">binutils-2.29</a> (juillet)</h2>
<p>La version 2.28 de cet ensemble d’outils de développement logiciel était parue en mars 2017. La version 2.29 apporte principalement la prise en charge de l’ia16 (x86 16 bits). Une version 2.28.1 est aussi parue, mais le journal des modifications ne fournit aucune info.</p>
<h2 id="cgicc-3218-et-3219-juin-et-juillet">
<a href="https://www.gnu.org/software/cgicc/">cgicc-3.2.18 et 3.2.19</a> (juin et juillet)</h2>
<p>Ces versions de la bibliothèque C++ pour écrire des applications <a href="https://fr.wikipedia.org/wiki/Common_Gateway_Interface">CGI</a> apportent quatre corrections de bogues pour la première et on ne sait pas quoi pour la seconde, dont le journal des modifications n’est pas renseigné.</p>
<h2 id="dr-geo-1707-juin">
<a href="https://www.gnu.org/software/dr-geo/">dr-geo-17.07</a> (juin)</h2>
<p>Cette version du logiciel de géométrie dynamique (souvent évoqué sur <a href="//linuxfr.org/tags/dr_geo/public"><em>LinuxFr.org</em></a>) corrige six bogues.</p>
<h2 id="freeipmi-156-juillet">
<a href="https://www.gnu.org/software/freeipmi/">freeipmi-1.5.6</a> (juillet)</h2>
<p>Ce logiciel implémente l’interface de gestion intelligente de matériel (ou IPMI, <em>Intelligent Platform Management Interface</em>). La version précédente datait de novembre 2016. Cette version amène des clarifications des messages d’erreur, des corrections de documentation, une correction sur une fuite de mémoire et l’utilisation dans <code>ipmi-locate</code> du microcode DMI sysfs s’il est disponible.</p>
<h2 id="gama-119-juillet">
<a href="https://www.gnu.org/software/gama/">gama-1.19</a> (juillet)</h2>
<p>La version précédente de ce logiciel d’ajustement des réseaux géodésiques était parue en août 2016. Cette version corrige un bogue introduit dans la version 1.16.</p>
<h2 id="gcc-640-juillet">
<a href="https://www.gnu.org/software/gcc/">gcc-6.4.0</a> (juillet)</h2>
<p>Une version de maintenance pour la suite de compilateurs, avec <a href="https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=6.4">102 problèmes corrigés</a>, dont la plus importante semble être un changement d’ABI sur ARM pour ne plus avoir de petites énumérations par défaut.</p>
<h2 id="gdb-80-juin">
<a href="https://www.gnu.org/software/gdb/">gdb-8.0</a> (juin)</h2>
<p>La nouvelle version du débogueur <em>gdb</em> apporte de nombreuses nouveautés. Les architectures MIPS sous FreeBSD et Synopsys ARC sont maintenant prises en charge. À l’inverse, les architectures Alpha sous FreeBSD et GNU/kFreeBSD ne sont plus prises en charge. On devrait également avoir une bonne prise en compte des registres PKU (<em>Protection Keys for Userspace</em>). Ces derniers, à travers les instructions RDPKRU / WRPKRU, devraient fournir un mécanisme de protection de la mémoire dans les futurs processeurs Intel.</p>
<p>Concernant les langages C++11 et Python, les <em>rvalues</em> sont mieux gérées. En outre, sur Windows, GDB identifie maintenant correctement le nom associé à un fil d’exécution. De plus, on peut enfin donner des commandes avec plus de dix arguments. On notera également que cette nouvelle version peut enregistrer et répéter correctement les commandes <code>rdrand</code> et <code>rdseed</code>.</p>
<h2 id="glpk-462-et-463-juinetjuillet">
<a href="https://www.gnu.org/software/glpk/">glpk-4.62 et 4.63</a> (juin et juillet)</h2>
<p>Deux versions ont été publiées pour cette bibliothèque de programmation linéaire en nombres entiers ou en nombres mixtes. La 4.62 amène l’ajout de la technique de <em>bound perturbation</em>, la correction d’un bogue dans la lecture MPS, l’amélioration de la portabilité 64 bits et le remplacement de fonctions non compatibles multi‐fils d’exécution (<em>non thread‐safe</em>) par leur équivalent sûr. La 4.63 apporte une perturbation intelligente des programmes linéaires, l’ajout de la technique <em>long‐step</em>, le changement d’échelle de l’objectif interne, une correction sur <em>glp_time</em> sur <em>msys2</em> et l’ajout de nouveaux modèles d’exemple.</p>
<h2 id="gnuastro-03-juin">
<a href="https://www.gnu.org/software/gnuastro/">gnuastro-0.3</a> (juin)</h2>
<p>Cet ensemble d’utilitaires pour l’astronomie a publié sa troisième version, qui est une réécriture complète, avec un nouveau conteneur générique pour les données.</p>
<h2 id="gnucash-2617-juillet">
<a href="https://www.gnu.org/software/gnucash/">gnucash-2.6.17</a> (juillet)</h2>
<p>Cette version du logiciel de comptabilité corrige de nombreux bogues concernant la modification des options de comptes ayant des transactions, les rapports concernant les devises étrangères, les liens dans le README du dépôt, le registre séparé des transactions, la traduction de devises étrangères, le respect du champ NUM pour le tri personnalisé, une correction sur un plantage en ajoutant un prix existant, une correction sur un plantage au lancement de la version 2.6.16, une faute dans une boîte de dialogue, mais aussi de nouvelles traductions (arabe et turc) et d’autres améliorations (espaces de nommage, <em>time64</em> mieux géré pour les dates, nouvelle devise, gestion d’un commentaire supplémentaire non standard sur une transaction).</p>
<h2 id="gnuhealth-320-et-321-juillet">
<a href="http://health.gnu.org/">gnuhealth-3.2.0 et 3.2.1</a> (juillet)</h2>
<p>Plusieurs versions sont parues pour ce progiciel libre dans le domaine de la santé. D’après la 3.2.0 qui amène l’intégration de Tryton 4.2, la migration en Python 3, une prise en charge améliorée de WebDAV et du calendrier, des paquets cryptographiques mis à jour, l’ajout d’un lien entre les commandes du labo et les services de santé, une amélioration de l’internationalisation, une mutualisation des variantes linguistiques, un nouveau test code 39, une nouvelle information personnelle prise en charge, la possibilité d’activer et désactiver les parties <em>Patient</em>, <em>Médicament</em> et <em>Services</em>, de nouveaux modules (gestion des urgences et des ambulances, des assurances santé et des prix, la base génétique Uniprot, la signature numérique des commandes du labo, l’intégration des commandes labo dans les services). Et surtout l’ajout de la fédération GNU Health avec un réseau de nœuds hétérogènes (le système d’information sur MongoDB, Thalamus le serveur d’authentification et de messagerie, HMIS, les applications mobiles, les centres de recherche, etc.).</p>
<p>La version 3.2.1 corrige uniquement un souci d’affichage dans la partie commandes labo.</p>
<p>On notera aussi la publication de la version 3.0.4 de <em>gnuhealth-control</em>, l’outil principal de gestion de l’environnement GNU Health (les changements dans ce script livré séparément ne sont pas détaillés).</p>
<h2 id="gnupg-2122-juillet">
<a href="https://gnupg.org/">gnupg-2.1.22</a> (juillet)</h2>
<p>GnuPG est un programme en ligne de commande qui permet de signer, chiffrer et déchiffrer les données et les communications. La principale nouveauté de cette version est la détection et l’utilisation automatique de TOR. L’option <code>--no-use-tor</code> permet de désactiver cette fonctionnalité. On notera également une meilleure prise en charge des serveurs en IPv6 et la possibilité d’utiliser TLS lorsque l’on passe par un serveur mandataire HTTP.</p>
<h2 id="gnutls-3513-et-3514-juinetjuillet">
<a href="https://www.gnu.org/software/gnutls/">gnutls-3.5.13 et 3.5.14</a> (juin et juillet)</h2>
<p>Cette bibliothèque pour gérer les protocoles SSL, TLS et DTLS connaît une version <a href="https://lists.gnupg.org/pipermail/gnutls-devel/2017-June/008446.html">3.5.13</a> (alerte GnuTLS-SA-2017-4) corrigeant divers bogues (sans changement d’<a href="https://fr.wikipedia.org/wiki/Interface_de_programmation">API</a> ou d’<a href="https://fr.wikipedia.org/wiki/Application_binary_interface">ABI</a>), concernant le (dé)chiffrement en place AES-GCM sur AArch64, le champ <code>ResponseID</code> qui n’est plus analysé, la tolérance à l’absence de codage temporel DER strict dans les certificats, la migration vers la <em>libtasn1</em> 4.11 et l’utilisation de certificats multiples avec <code>certool --p7-sign</code>. Puis une version <a href="https://lists.gnupg.org/pipermail/gnutls-devel/2017-July/008469.html">3.5.14</a>, toujours sans changement d’API/ABI, pour la gestion de matériels de gestion de clefs (HSM) demandant une autorisation explicite, avoir un drapeau pour obliger l’authentification via le HSM, éviter les zéros en tête dans les copies d’entiers sur certains HSM ou corriger la découverte OCSP, ainsi qu’une version <a href="https://lists.gnupg.org/pipermail/gnutls-devel/2017-July/008468.html">3.3.28</a> de maintenance sur la précédente version stable.</p>
<h2 id="grep-31-juillet">
<a href="https://www.gnu.org/software/grep/">grep-3.1</a> (juillet)</h2>
<p>Une nouvelle version stable de ce programme en ligne de commande de recherche de chaînes de caractères apporte en amélioration les mêmes performances pour <code>[0-9]</code> et <code>[[:digit:]]</code> avec une <em>locale</em> multi‐octet et en changement de comportement le fait que le contexte n’exclut plus les lignes omises en raison de <code>-m</code> (<code>grep "^" -m1 -A1</code> affiche les deux premières lignes). Et sous Windows, une option <code>--binary (-U)</code> vient remplacer l’heuristique parfois incorrecte de gestion d’entrées‐sorties binaires et l’option <code>--unix-byte-offsets (-u)</code> devient sans effet.</p>
<h2 id="gsl-24-juin">
<a href="https://www.gnu.org/software/gsl/">gsl-2.4</a> (juin)</h2>
<p>Cette version de la bibliothèque en C fournissant des outils de calcul numérique en mathématiques appliquées migre la documentation vers Sphinx, rajoute de la constance sur les routines <em>gsl_rstat</em>, corrige des bogues, ajoute du calcul d’intégrales avec IQPACK, des polynômes d’Hermite et des exemples, rend obsolète et remplace quelques routines, etc.</p>
<h2 id="guile-cv-015-juillet">
<a href="https://www.gnu.org/software/guile-cv/">guile-cv-0.1.5</a> (juillet)</h2>
<p>La version précédente de cette bibliothèque de vision par ordinateur pour Guile Scheme était la première publique et la première incluse dans le projet GNU. Cette version apporte des changements d’interface (renommage <code>dark/light</code> par <code>black/white</code>) et de nouvelles interfaces (<code>im-delineate</code>, <code>im-delineate-channel</code>, <code>im-distance-map</code>, <code>im-distance-map-channel</code>, <code>im-canny</code>, <code>im-canny-channel</code>, <code>im-xor</code> et <code>f32vector-xor-at-offset</code>).</p>
<h2 id="guile-gnome-2165-juin">
<a href="https://www.gnu.org/software/guile-gnome/">guile-gnome-2.16.5</a> (juin)</h2>
<p>Cette version de cette bibliothèque donnant accès en langage Guile aux bibliothèques GNOME est une version de maintenance, compatible avec Guile 2.2.</p>
<h2 id="libextractor-14-juin">
<a href="https://www.gnu.org/software/libextractor/">libextractor-1.4</a> (juin)</h2>
<p>Cette version de cette bibliothèque extrayant les métadonnées des fichiers (qui n’avait pas connu de mises à jour depuis trois ans et demi) amène la gestion d’<a href="https://fr.wikipedia.org/wiki/AppArmor" title="Définition Wikipédia">AppArmor</a>, des PDF via <em>pdfinfo</em>, la migration de Subversion à Git, la compilation avec <em>libexiv</em> 0.26 et la suppression de l’utilisation de l’en‐tête obsolète <em>libtidy</em>.</p>
<h2 id="libffcall-113-juin">
<a href="https://www.gnu.org/software/libffcall/">libffcall-1.13</a> (juin)</h2>
<p>Cette version de cette collection de quatre bibliothèques d’appel de fonctions externes amène un changement de licence (de GPL v2 à GPL v2+), ajoute neuf nouvelles plates‐formes prises en charge, corrige la gestion d’onze plates‐formes, a vérifié la bonne gestion de huit autres plates‐formes et ajoute une fonctionnalité de sécurité pour Linux et FreeBSD en empêchant le pile d’être exécutable.</p>
<h2 id="libgcrypt-177-et-180-juin-et-juillet">
<a href="https://gnupg.org/software/libgcrypt/index.html">libgcrypt-1.7.7 et 1.8.0</a> (juin et juillet)</h2>
<p>Le support de la branche 1.6 de cette bibliothèque de cryptographie a expiré à la fin du mois de juin 2017. La branche 1.7 devrait recevoir des mises à jour de sécurité jusqu’à la fin du mois de juin 2019. La version 1.7.7 corrige ainsi deux bogues, l’un dans la gestion de la mémoire sécurisée, l’autre dans la gestion des clefs EdDSA.</p>
<p>La nouvelle version stable de <em>libgcrypt</em> est donc la branche 1.8. Elle présente des API et ABI totalement compatibles avec la branche 1.7. Les principales nouveautés sont l’ajout de la fonction de hachage Blake-2, le chiffrement de type XTS pour les blocs de 16 octets et un meilleur générateur de nombres aléatoires.</p>
<h2 id="libidn2-203-juillet">
<a href="https://www.gnu.org/software/libidn/#libidn2">libidn2-2.0.3</a> (juillet)</h2>
<p>Cette bibliothèque gère le codage et le décodage des noms de domaine internationalisés suivant les spécifications IDNA 2008 et TR 46 (RFC <a href="https://tools.ietf.org/html/rfc5890">5890</a>, <a href="https://tools.ietf.org/html/rfc5891">5891</a>, <a href="https://tools.ietf.org/html/rfc5892">5892</a>, <a href="https://tools.ietf.org/html/rfc5893">5893</a> et <a href="http://www.unicode.org/reports/tr46/">TR 46</a>). Cette version corrige notamment une régression en désactivant par défaut la règle <code>%IDN2_USE_STD3_ASCII_RULES</code> filtrant les caractères non STD3 dans les noms de domaine (comme <code>_443._tcp.example.com</code>) et les IP (comme <code>1.2.3.4/24</code>), et modernise l’infrastructure de génération <em>gtk-doc</em>.</p>
<h2 id="libmicrohttpd-0955-juin">
<a href="https://www.gnu.org/software/libmicrohttpd/">libmicrohttpd-0.9.55</a> (juin)</h2>
<p>Cette bibliothèque qui évolue visiblement assez vite fournit un micro‐serveur Web en C. Cette version amène diverses corrections, des améliorations sur les connexions reprises, mises à jour <code>upgrade</code> ou sur les <em>Keep-Alive</em> et <em>Close</em>.</p>
<h2 id="libtasn1-412-juin">
<a href="https://www.gnu.org/software/libtasn1/">libtasn1-4.12</a> (juin)</h2>
<p>La version 4.11 de cette bibliothèque <a href="https://fr.wikipedia.org/wiki/ASN.1" title="Définition Wikipédia">ASN.1</a> comportait une erreur de version dans le nommage du <code>.so</code>, corrigée en 4.12. Mais les nouveautés viennent donc de la version précédente : un nouveau code d’erreur <code>ASN1_TIME_ENCODING_ERROR</code>, un nouveau drapeau <code>ASN1_DECODE_FLAG_ALLOW_INCORRECT_TIME</code> pour le mode strict DER et une vérification de la longueur des noms de variables par le développeur.</p>
<h2 id="linux-libre-4117-gnu-et-4123-gnu-juinetjuillet">
<a href="http://www.fsfla.org/ikiwiki/selibre/linux-libre/">linux-libre-4.11.7-gnu et 4.12.3-gnu</a> (juin et juillet)</h2>
<p>Le <a href="http://www.fsfla.org/ikiwiki/selibre/linux-libre/">projet</a> vise à publier et maintenir le noyau Linux 100 % libre. Les principaux blocs binaires (<em>blobs</em>) sont présents dans les pilotes graphiques, mais aussi pour l’accélération cryptographique, l’Ethernet ou l’écran tactile, et chaque nouvelle version du noyau amène en général son lot de nouveaux blocs binaires.</p>
<h2 id="moe-19-juillet">
<a href="https://www.gnu.org/software/moe/">moe-1.9</a> (juillet)</h2>
<p>Une nouvelle version pour l’éditeur de texte en console, seize mois après la précédente : lecture récursive des arborescences par défaut, nouveaux raccourcis clavier, plus de caractères UTF-8 décodés, la position du curseur est affichée ajustée pour les tabulations, les commentaires <code>/* */</code> sont évités dans la recherche de délimitation associée, la recherche inverse a été ajoutée, l’entrée standard n’est lue qu’une fois, la déduplication de lignes est accélérée de 20 %, les noms longs de fichiers sont affichés abrégés, la <em>locale</em> C est utilisée dans Cygwin pour les caractères au‐dessus de 127 et une correction sur le test de <em>g++</em> dans le <em>configure</em>.</p>
<h2 id="motti-311-juin">
<a href="https://www.gnu.org/software/motti/">motti-3.1.1</a> (juin)</h2>
<p>Ce jeu de stratégie simple, multijoueur et en réseau n’avait pas connu de version depuis trois ans, et le but de celle‐ci est de le faire compiler proprement.</p>
<h2 id="nano-285-et-286-juinetjuillet">
<a href="https://www.nano-editor.org/news.php">nano-2.8.5 et 2.8.6</a> (juin et juillet)</h2>
<p>L’éditeur de texte <em>nano</em> a connu deux versions baptisées <code>Farouche</code> et <code>Kekulé</code>, notamment pour permettre une césure différente entre les mots (via <code>--atblanks</code>), pour éviter des plantages, pour corriger divers bogues, pour harmoniser les fichiers <em>rc</em>, pour renommer l’option <code>cut</code> en <code>cutfromcursor</code>, pour permettre les numéros négatifs de ligne et de colonne en ligne de commande, pour éviter les clignotements au redimensionnement de la fenêtre, pour ouvrir les fichiers dans l’ordre demandé en ligne de commande et pour mieux gérer le signal <code>SIGCONT</code>.</p>
<pre><code> ::: The
iLE88Dj. :jD88888Dj:
.LGitE888D.f8GjjjL8888E; .d8888b. 888b 888 888 888
iE :8888Et. .G8888. d88P Y88b 8888b 888 888 888
;i E888, ,8888, 888 888 88888b 888 888 888
D888, :8888: 888 888Y88b 888 888 888
D888, :8888: 888 88888 888 Y88b888 888 888
D888, :8888: 888 888 888 Y88888 888 888
D888, :8888: Y88b d88P 888 Y8888 Y88b. .d88P
888W, :8888: "Y8888P88 888 Y888 "Y88888P"
W88W, :8888:
W88W: :8888: 88888b. 8888b. 88888b. .d88b.
DGGD: :8888: 888 "88b "88b 888 "88b d88""88b
:8888: 888 888 .d888888 888 888 888 888
:W888: 888 888 888 888 888 888 Y88..88P
:8888: 888 888 "Y888888 888 888 "Y88P"
E888i
tW88D Text Editor Homepage
</code></pre>
<h2 id="parallel-20170622-et-20170722-juin-et-juillet">
<a href="https://www.gnu.org/software/parallel/">parallel-20170622 et 20170722</a> (juin et juillet)</h2>
<p>Cet outil <em>shell</em> permet d’exécuter des tâches en parallèle sur un ou plusieurs ordinateurs. La version 20170622 <em>Manchester</em> autorise le <code>\257</code> / <code>U+02C9</code> (<a href="https://fr.wikipedia.org/wiki/Macron_(diacritique)">macron</a> « <code>ˉ</code> », qui était aussi le nom de la version précédente 20170522) dans la ligne de commande. Rien de nouveau dans la version 20170722 <em>Grenfell</em> (nouvelle version stable), seulement des correctifs et des mises à jour de manuel.</p>
<p><img src="//img.linuxfr.org/img/68747470733a2f2f7777772e676e752e6f72672f736f6674776172652f706172616c6c656c2f6c6f676f2d677261792b626c61636b3330302e706e67/logo-gray+black300.png" alt="Logo" title="Source : https://www.gnu.org/software/parallel/logo-gray+black300.png"></p>
<h2 id="screen-460-et-461-juin-et-juillet">
<a href="https://www.gnu.org/software/screen/">screen-4.6.0 et 4.6.1</a> (juin et juillet)</h2>
<p>Ce logiciel de console virtuelle permet de partager un terminal en plusieurs processus. La version 4.6.0 gère les tables Unicode 9.0, plus de débits différents en série, améliore les espaces de nommage, migre des FIFO aux <em>sockets</em> et débute le défilement arrière à la première ligne d’affichage. La version 4.6.1 apporte l’installation parallélisée et corrige des bogues. (le fichier <code>Changelog</code> est renseigné, mais pas le fichier <code>NEWS</code> qui évoque encore les versions 4.0.<em>x</em>).</p>
<h2 id="taler-030-juin">
<a href="https://www.gnu.org/software/taler/">taler-0.3.0</a> (juin)</h2>
<p>Cette <a href="http://lists.gnu.org/archive/html/taler/2017-06/msg00000.html">version</a> de ce système de paiement électronique avec anonymat du client est encore au stade alpha :</p>
<ul>
<li>le protocole d’échange complet est implémenté mais sans connexion avec une banque réelle (uniquement avec leur propre « banque ») ;</li>
<li>le portefeuille (pour Chromium/Chrome, Firefox et Opéra) permet le retrait, la dépense et l’actualisation, mais pas le remboursement, la synchronisation ou l’exportation de preuves cryptographiques, et la gestion des erreurs pourrait être insuffisante ;</li>
<li>le <em>backend</em> marchand génère des contrats, gère les paiements et leur suivi (implémentations de frontaux disponibles en Python et PHP) ;</li>
<li>la banque peut gérer les comptes, permet le retrait de fonds par le portefeuille et recevoir des paiements depuis l’échangeur ;</li>
<li>l’auditeur peut vérifier les preuves cryptographiques collectées par le fournisseur de la solution de paiement et calculer les montants attendus, mais il ne vérifie pas encore que la banque a fait les mêmes calculs.</li>
</ul><p><img src="//img.linuxfr.org/img/687474703a2f2f7069782e746f696c652d6c696272652e6f72672f75706c6f61642f6f726967696e616c2f313530333135323836342e706e67/1503152864.png" alt="GNU Taler" title="Source : http://pix.toile-libre.org/upload/original/1503152864.png"></p>
<h2 id="texinfo-64-juin">
<a href="https://www.gnu.org/software/texinfo/">texinfo-6.4</a> (juin)</h2>
<p>Cette nouvelle version du langage de formatage de texte amène des évolutions sur plusieurs outils :</p>
<ul>
<li>
<code>texi2any</code> : les noms de section apparaissent avant dans les titres, retour à la numérotation initiale des listes comme dans les versions 4.13 et précédentes, rapidité accrue, des corrections sur le formatage Perl et le retrait de fonctions ne faisant pas ce qui était annoncé ;</li>
<li>
<code>info</code> : <code>up-line</code> et <code>down-line</code> ne sont plus confinées à un nœud, <code>--all</code> peut être utilisé avec <code>--index-search</code> pour lister les entrées correspondantes, <code>link-style</code> peut être défini pendant l’exécution, une correction sur la désactivation prématurée des couleurs, divers bogues corrigés, une suite de test plus portable, le retrait de la conversion intelligente des fins de ligne « à la Windows » et quelques raccourcis clavier modifiés ;</li>
<li>
<em>texinfo.tex</em> peut à nouveau générer une page unique vide comme les versions 6.0 et précédentes.</li>
</ul><h2 id="tramp-232-juillet">
<a href="https://www.gnu.org/software/tramp/">tramp-2.3.2</a> (juillet)</h2>
<p>Cette version du logiciel gérant les accès à des ressources distantes dans Emacs suit le changement de version de l’éditeur couteau suisse (de 23 à 24).</p>
<h2 id="unifont-10001-à-10005-juinetjuillet">
<a href="https://www.gnu.org/software/unifont/">unifont-10.0.01 à 10.0.05</a> (juin et juillet)</h2>
<p>Des nombreuses versions de cette police matricielle couvrant toutes les identifications numériques Unicode BMP ont été publiées, pour suivre Unicode 10.0.0, améliorer les glyphes à largeur triple et quadruple, les émoticônes, l’outil <em>hex2sfd</em> (ASCII hexadécimal vers FontForge), ajouter l’option <code>-P</code> (plan) pour <em>unifontpic</em>, le champ <code>x-offset</code> pour le rendu, ajuster divers glyphes, etc.</p>
<h2 id="conclusion">Conclusion</h2>
<p>Dans la dépêche précédente, la question était « Y a‐t‐il un intérêt à écrire une telle dépêche ? ». À titre personnel, la réponse était oui, et d’après les commentaires, d’autres personnes étaient intéressées. Merci à <a href="//linuxfr.org/users/mathrack"><em>mathrack</em></a> pour ses contributions sur cette dépêche. N’hésitez donc pas à participer à sa rédaction et aux dépêches à venir.</p></div><div><a href="https://linuxfr.org/news/nouvelles-versions-logicielles-du-projet-gnu-juin-et-juillet-2017.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/112466/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/nouvelles-versions-logicielles-du-projet-gnu-juin-et-juillet-2017#comments">ouvrir dans le navigateur</a>
</p>
Benoît SibaudDavy DefaudAnonymepalm123https://linuxfr.org/nodes/112466/comments.atomtag:linuxfr.org,2005:Diary/373522017-06-08T00:02:25+02:002017-06-08T00:02:25+02:00GnuPG lance une nouvelle campagne de financementLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<h2 class="sommaire">Sommaire</h2>
<ul class="toc">
<li><ul>
<li><a href="#pgp-openpgp-gnupg--petit-rappel-des-faits">PGP, OpenPGP, GnuPG : petit rappel des faits</a></li>
<li><a href="#g10code-gmbh">g10code GmbH</a></li>
<li><a href="#lenvol%C3%A9e">L’envolée</a></li>
<li><a href="#et-maintenant-gnupg-a-besoin-de-vous">Et maintenant, GnuPG a besoin de vous !</a></li>
</ul></li>
</ul><p>Après s’être sorti d’une mauvaise passe il y a quelques années grâce à une campagne de financement réussie et aux contributions de quelques grosses entreprises, <a href="https://gnupg.org/">GnuPG</a> cherche aujourd’hui à pérenniser ses ressources et lance à cette fin <a href="https://gnupg.org/blog/20170606-campaign-launch.html">une nouvelle campagne de financement</a> où l’accent est mis sur la récurrence des dons et l’importance des donateurs individuels.</p>
<h3 id="pgp-openpgp-gnupg--petit-rappel-des-faits">PGP, OpenPGP, GnuPG : petit rappel des faits</h3>
<p>Au début des années 1990, Phil Zimmerman écrivit <em>PGP</em> (<em>Pretty Good Privacy</em>), un logiciel de chiffrement et signature de fichiers et de messages. C’était alors l’un des premiers, sinon le premier, logiciels mettant la cryptographie à la portée du grand public, ce qui ne fut pas sans valoir quelques ennuis à Phil Zimmerman de la part du gouvernement américain. Quelques années plus tard, afin de permettre le développement de logiciels compatibles avec PGP (tout les éditeurs de logiciels n’ont pas forcément l’obsession d’enfermer leurs utilisateurs), le format des messages manipulés par PGP fut décrit successivement dans les <a href="https://tools.ietf.org/html/rfc1991">RFC 1991</a> puis <a href="https://tools.ietf.org/html/rfc2440">2440</a>, où il fut alors appelé <em>format OpenPGP</em>.</p>
<p>PGP n’était pas un logiciel <em>libre</em>. Le code source était, à l’époque, diffusé avec chaque copie, mais sans les libertés traditionnellement associées aux logiciels libres (notamment, la liberté d’utilisation commerciale). Et certains algorithmes utilisés (notamment RSA) étaient encombrés de brevets. Richard Stallman, initiateur du projet GNU et fondateur de la FSF, reconnaissant l’intérêt d’un tel logiciel, exhorta alors la communauté des hackers à développer une implémentation <em>libre</em> du nouveau standard OpenPGP.</p>
<p>Détail important, cet appel était destiné aux développeurs <em>non-américains</em> et principalement <em>européens</em>, la législation de plusieurs pays du vieux continent étant globalement plus favorable à la cryptographie : un logiciel développé aux États-Unis par des hackers américains aurait pu se heurter à la législation américaine qui assimile les logiciels de cryptographie à des munitions de guerre — c’est ainsi que PGP fut initialement confiné aux USA, dont il ne put sortir que sous la forme d’un livre contenant son code source édité par le MIT, forme sous laquelle il était protégé par le premier amendement de la constitution américaine.</p>
<p>L’appel de rms fut entendu en septembre 1997 par un développeur allemand, Werner Koch, qui s’attela à la tâche et <a href="https://lists.gnupg.org/pipermail/gnupg-devel/1997-December/014131.html">publia trois mois plus tard</a> la version 0.0.0 de <em>G10, The Free PGP Replacement</em>.<sup id="fnref1"><a href="#fn1">1</a></sup> Le projet de Werner Koch fut par la suite renommé en <em>GnuPG</em> (<em>GNU Privacy Guard</em>),<sup id="fnref2"><a href="#fn2">2</a></sup> souvent abrégé en <em>gpg</em> qui est aussi le nom du binaire principal. La version 1.0.0 fut publiée en septembre 1999.</p>
<h3 id="g10code-gmbh">g10code GmbH</h3>
<p><a href="https://g10code.com/">g10code GmbH</a> est l’entreprise fondée par Werner Koch et son frère en 2001 pour fournir un cadre légal au développement de GnuPG. g10code propose du développement à la demande et du support autour de GnuPG. L’entreprise a notamment été mandatée par le ministère allemand des finances pour porter le logiciel sous Windows, et par le BSI (<em>Bundesamt für Sicherheit in der Informationstechnik</em>, l’équivalent allemand de l’ANSSI) pour implémenter la prise en charge de <a href="https://tools.ietf.org/html/rfc5751">S/MIME</a>, l’autre standard de chiffrement de messages « concurrent » d’OpenPGP — ce projet, nom de code <em>Aegypten</em>, a donné naissance à GnuPG 2.</p>
<p>À partir de la fin des années 2000, g10code va toutefois traverser une passe difficile. Le manque de contrats de développement et de support va conduire l’entreprise à se séparer de Marcus Brinkmann en 2012, Werner Koch restant alors le seul employé. En 2013, la situation devient critique au point que Werner Koch envisage de plus en plus de laisser tomber et de trouver un boulot de « développeur normal » (<em>straight coder job</em>).</p>
<p>Hasard de l’histoire, c’est à ce moment qu’un certain Edward Snowden, ancien contractant de la NSA, révèle au monde entier l’étendue des programmes de surveillance de masse des services de renseignement américains. L’affaire fait grand bruit, suscite un (relatif) regain d’intérêt pour les questions liées à la protection et à la violation de la vie privée, et surtout motive Werner Koch à ne pas abandonner le projet GnuPG.</p>
<p>Il faudra toutefois attendre le succès de la campagne de financement de début 2015, le support de la <a href="https://www.coreinfrastructure.org/">Core Infrastructure Initiative</a> et de deux grosses entreprises (Facebook et Stripe) pour que <a href="//linuxfr.org/news/gnupg-utilise-gnupg-oublie-mais-gnupg-finance">la situation de g10code s’améliore</a>.</p>
<h3 id="lenvolée">L’envolée</h3>
<p>Dès lors, GnuPG a connu un développement accéléré qui continue encore aujourd’hui.</p>
<p>Cela a commencé avec la sortie de la première version de la branche 2.1, en novembre 2014. Cette version a introduit, entre autres :</p>
<ul>
<li>une nouvelle architecture avec une séparation plus franche des responsabilités entre les différents composants (notamment, désormais seul ’agent GnuPG manipule directement les clefs secrètes) — la branche 2.0 avait déjà initié cette réorganisation mais sans aller jusqu’au bout ;</li>
<li>un nouveau format de stockage des clefs publiques, plus efficace pour les trousseaux bien fournis ;</li>
<li>la prise en charge des algorithmes basés sur les courbes elliptiques (<a href="https://tools.ietf.org/html/rfc6637">RFC 6637</a>).</li>
</ul><p>C’est cette branche qui concentre depuis l’essentiel des développements (les branches 1.4 et 2.0 sont en maintenance) et accueille toutes les nouvelles fonctionnalités, parmi lesquelles :</p>
<ul>
<li>un nouveau modèle de confiance, le modèle <em>Trust-on-first-use</em> (TOFU) (dont votre serviteur a déjà parlé <a href="//linuxfr.org/users/gouttegd/journaux/de-la-confiance-dans-le-monde-openpgp">dans son journal sur les modèles de confiance</a>) — une fonctionnalité majeure, susceptible de vraiment rendre GnuPG accessible au plus grand nombre en supprimant la nécessité de comprendre les arcanes de la toile de confiance (car, comme le disait Richard Feynman, « personne ne comprend la toile de confiance ») ;</li>
<li>une nouvelle façon de publier les clefs dans le DNS, <a href="https://tools.ietf.org/html/rfc7929">standardisée auprès de l’IETF</a> — GnuPG permettait déjà ça depuis des années mais utilisait une méthode qui lui était propre (un sujet <a href="//linuxfr.org/users/gouttegd/journaux/de-la-distribution-des-clefs-openpgp#publication-des-clefs-dans-le-dns">également couvert</a> par votre serviteur dernièrement) — par ailleurs déjà mise en œuvre par certains fournisseurs de service de messagerie outre-Rhin ;</li>
<li>une nouvelle façon de publier les clefs sur le web, le <a href="//linuxfr.org/users/gouttegd/journaux/de-la-distribution-des-clefs-openpgp#le-protocole-openpgp-web-key-service">Web Key Directory</a> ;</li>
<li>la prise en charge de Tor pour la communication avec les serveurs de clefs ;</li>
<li>un nouveau <em>framework</em> de tests unitaires assurant un meilleur contrôle qualité et une réduction des risques de régression ;</li>
<li>beaucoup de travail sur les <em>bindings</em> Python de GPGME (<em>GnuPG Made Easy</em>, la bibliothèque permettant d’utiliser GnuPG depuis son code) ;</li>
<li>(liste non-exhaustive).</li>
</ul><h3 id="et-maintenant-gnupg-a-besoin-de-vous">Et maintenant, GnuPG a besoin de vous !</h3>
<p>Après la campagne de financement de 2015 évoquée plus haut, les développeurs visent désormais la stabilité à long terme. L’objectif de <a href="https://gnupg.org/donate/">la campagne 2017</a> est d’obtenir des promesses de dons récurrents garantissant à g10code au moins 15 000 euros par mois.</p>
<p>Cet argent permettra à g10code de continuer à employer trois développeurs à temps plein : Marcus Brinkmann (qui est de retour après son départ en 2012), Neal Walfied, et Justus Winter.</p>
<p>Pour en savoir plus, les anglophones peuvent consulter les vidéos à disposition sur <a href="https://gnupg.org/donate/">le site de la campagne de financement</a>. Les développeurs de GnuPG y expliquent leur travail, et des utilisateurs (activistes, journalistes, ONG, etc.) témoignent de l’importance de GnuPG pour leurs activités.</p>
<p>Rappelons par ailleurs, comme le fait Daniel Kahn Gillmor (mainteneur de GnuPG pour Debian), que la plupart des distributions GNU/Linux s’appuient sur GnuPG pour garantir l’intégrité de leurs paquetages et de leurs mises à jour.</p>
<div class="footnotes">
<hr>
<ol>
<li id="fn1">
<p>Le nom « G10 » est une référence à la fois à l’article 10 de <a href="http://www.cjfa.eu/REPOSITORY/EDCJFA_3.pdf#page=14">la constitution allemande</a> (<em>Grundgesetz</em>, loi fondamentale), qui garantit que le secret des correspondances est inviolable, et à <a href="https://en.wikipedia.org/wiki/Gesetz_zur_Beschr%C3%A4nkung_des_Brief-,_Post-_und_Fernmeldegeheimnisses">la loi sur les restrictions au secret des correspondances</a>, elle-même surnommée « loi G-10 », qui autorise les services de renseignement allemands à ne pas considérer le secret des correspondances comme si inviolable que ça. <a href="#fnref1">↩</a></p>
</li>
<li id="fn2">
<p>Pour l’anecdote, rms a approuvé le nom <em>GnuPG</em> mais aurait préféré <a href="https://lists.gnupg.org/pipermail/gnupg-devel/1998-January/014162.html">un nom plus drôle ou plus coquin</a>. <a href="#fnref2">↩</a></p>
</li>
</ol>
</div><div><a href="https://linuxfr.org/users/gouttegd/journaux/gnupg-lance-une-nouvelle-campagne-de-financement.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/112043/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/gouttegd/journaux/gnupg-lance-une-nouvelle-campagne-de-financement#comments">ouvrir dans le navigateur</a>
</p>
gouttegdhttps://linuxfr.org/nodes/112043/comments.atomtag:linuxfr.org,2005:News/380302017-06-05T00:08:58+02:002017-06-05T17:31:48+02:00Nouvelles versions logicielles du projet GNU avril et mai 2017Licence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<div><p>Le projet GNU publie tous les mois une liste de versions logicielles publiées. Jetons‐y un coup d’œil pour découvrir de nouveaux logiciels inconnus (de moi), des infâmes bogues disparus ou les promesses de solutions à tous nos besoins : soit 33 nouvelles versions annoncées allant de la corrective mineure à la version attendue depuis des années ; et l’on va donc parler de <code>acct</code>, <code>artanis</code>, <code>bc</code>, <code>diffutils</code>, <code>emacs</code>, <code>emms</code>, <code>freedink-data</code>, <code>gcc</code>, <code>global</code>, <code>gnubik</code>, <code>gnupg</code>, <code>gnutls</code>, <code>grub</code>, <code>guile</code>, <code>guile-cv</code>, <code>guile-ncurses</code>, <code>icecat</code>, <code>kawa</code>, <code>less</code>, <code>libcdio-paranoia</code>, <code>libidn2</code>, <code>libmicrohttpd</code>, <code>linux-libre</code>, <code>nano</code>, <code>ocrad</code>, <code>orgadoc</code> et <code>parallel</code>.</p></div><ul><li>lien nᵒ 1 : <a title="http://www.fsf.org/blogs/community/sixteen-new-gnu-releases-in-the-month-of-may" hreflang="en" href="https://linuxfr.org/redirect/99978">Sixteen new GNU releases in the month of May </a></li><li>lien nᵒ 2 : <a title="http://www.fsf.org/blogs/community/seventeen-new-gnu-releases-in-the-month-of-april" hreflang="en" href="https://linuxfr.org/redirect/99979">Seventeen new GNU releases in the month of April </a></li><li>lien nᵒ 3 : <a title="https://lists.gnu.org/mailman/listinfo/info-gnu" hreflang="en" href="https://linuxfr.org/redirect/99980">Liste de diffusion info-gnu pour toutes les annonces</a></li></ul><div><h2 class="sommaire">Sommaire</h2>
<ul class="toc">
<li>
<a href="#acct-663-avril"></a><a href="https://www.gnu.org/software/acct/">acct-6.6.3</a> (avril)</li>
<li>
<a href="#artanis-021-mai"></a><a href="http://lists.gnu.org/archive/html/artanis/2017-05/msg00004.html">artanis-0.2.1</a> (mai)</li>
<li>
<a href="#bc-1071-avril"></a><a href="https://www.gnu.org/software/bc/">bc-1.07.1</a> (avril)</li>
<li>
<a href="#diffutils-36-mai"></a><a href="https://www.gnu.org/software/diffutils/">diffutils-3.6</a> (mai)</li>
<li>
<a href="#emacs-252-avril"></a><a href="https://www.gnu.org/software/emacs/index.html#Releases">emacs-25.2</a> (avril)</li>
<li>
<a href="#emms-43-mai"></a><a href="https://www.gnu.org/software/emms/">emms-4.3</a> (mai)</li>
<li>
<a href="#freedink-data-10820170409-avril"></a><a href="https://www.gnu.org/software/freedink/">freedink-data-1.08.20170409</a> (avril)</li>
<li>
<a href="#gcc-710-mai"></a><a href="https://www.gnu.org/software/gcc/gcc-7/changes.html">gcc-7.1.0</a> (mai)</li>
<li>
<a href="#global-657-mai"></a><a href="https://www.gnu.org/software/global/">global-6.5.7</a> (mai)</li>
<li>
<a href="#gnubik-243-avril"></a><a href="https://www.gnu.org/software/gnubik/">gnubik-2.4.3</a> (avril)</li>
<li>
<a href="#gnupg-2121-mai"></a><a href="https://lists.gnupg.org/pipermail/gnupg-announce/2017q2/000405.html">gnupg-2.1.21</a> (mai)</li>
<li>
<a href="#gnutls-3512-mai"></a><a href="https://lists.gnupg.org/pipermail/gnutls-devel/2017-May/008427.html">gnutls-3.5.12</a> (mai)</li>
<li>
<a href="#grub-202-avril"></a><a href="http://lists.gnu.org/archive/html/grub-devel/2017-04/msg00077.html">grub-2.02</a> (avril)</li>
<li>
<a href="#guile-222-et221-avril"></a><a href="https://www.gnu.org/software/guile/news/gnu-guile-222-released.html">guile-2.2.2</a> (et <a href="https://www.gnu.org/software/guile/news/gnu-guile-221-released.html">2.2.1</a>) (avril)</li>
<li>
<a href="#guile-cv-014-mai"></a><a href="https://www.gnu.org/software/guile-cv/news.html">guile-cv-0.1.4</a> (mai)</li>
<li>
<a href="#guile-ncurses-22-avril"></a><a href="https://www.gnu.org/software/guile-ncurses/">guile-ncurses-2.2</a> (avril)</li>
<li>
<a href="#icecat-5202-gnu1-avril-et-5210-gnu1-mai"></a><a href="https://www.gnu.org/software/gnuzilla/">icecat-52.0.2-gnu1 (avril) et 52.1.0-gnu1 (mai)</a>
</li>
<li>
<a href="#kawa-24-mai"></a><a href="https://www.gnu.org/software/kawa/news.html">kawa-2.4</a> (mai)</li>
<li>
<a href="#less-487-avril"></a><a href="https://www.gnu.org/software/less/">less-487</a> (avril)</li>
<li>
<a href="#libcdio-paranoia-1020941-avril"></a><a href="https://www.gnu.org/software/libcdio/">libcdio-paranoia-10.2+0.94+1</a> (avril)</li>
<li>
<a href="#libidn2-201-avril-et202-mai"></a><a href="https://www.gnu.org/software/libidn/">libidn2-2.0.1 (avril) et 2.0.2 (mai)</a>
</li>
<li>
<a href="#libmicrohttpd-0953-avril-puis0954-et0955-mai"></a><a href="https://www.gnu.org/software/libmicrohttpd/">libmicrohttpd-0.9.53 (avril) puis 0.9.54 et 0.9.55 (mai)</a>
</li>
<li>
<a href="#linux-libre-41012-gnu-avril-et4112-gnu-mai"></a><a href="http://www.fsfla.org/ikiwiki/selibre/linux-libre/">linux-libre-4.10.12-gnu (avril) et 4.11.2-gnu (mai)</a>
</li>
<li>
<a href="#nano-281-avril-%C3%A0284-mai"></a><a href="https://www.nano-editor.org/news.php">nano-2.8.1 (avril) à 2.8.4 (mai)</a>
</li>
<li>
<a href="#ocrad-026-avril"></a><a href="http://lists.gnu.org/archive/html/bug-ocrad/2017-04/msg00000.html">ocrad-0.26 (avril)</a>
</li>
<li>
<a href="#orgadoc-09-mai"></a><a href="http://savannah.gnu.org/projects/orgadoc/">orgadoc-0.9 (mai)</a>
</li>
<li>
<a href="#parallel-20170422-et20170522"></a><a href="https://www.gnu.org/software/parallel/">parallel-20170422 et 20170522</a>
</li>
<li><a href="#conclusion">Conclusion</a></li>
</ul><h2 id="acct-663-avril">
<a href="https://www.gnu.org/software/acct/">acct-6.6.3</a> (avril)</h2>
<p>Il s’agit d’une mise à jour mineure de cet outil d’enregistrement des actions sur le système (nom d’utilisateur et processus), pour incorporer des correctifs venant de SUSE et Red Hat.</p>
<h2 id="artanis-021-mai">
<a href="http://lists.gnu.org/archive/html/artanis/2017-05/msg00004.html">artanis-0.2.1</a> (mai)</h2>
<p>On y trouve quelques corrections de bogues et un peu plus de robustesse pour cette boîte à outils pour applications Web (<a href="https://en.wikipedia.org/wiki/Web_framework">WAF</a>) en Guile Scheme.</p>
<h2 id="bc-1071-avril">
<a href="https://www.gnu.org/software/bc/">bc-1.07.1</a> (avril)</h2>
<p>La version apporte principalement des compléments documentaires et quelques corrections de bogues pour cette calculatrice à précision arbitraire.</p>
<h2 id="diffutils-36-mai">
<a href="https://www.gnu.org/software/diffutils/">diffutils-3.6</a> (mai)</h2>
<p>Cet ensemble d’outils pour comparer des fichiers reçoit une nouvelle fonctionnalité (si un fichier comparé est le début de l’autre), des corrections de bogues et une amélioration de performance sur les gros fichiers.</p>
<h2 id="emacs-252-avril">
<a href="https://www.gnu.org/software/emacs/index.html#Releases">emacs-25.2</a> (avril)</h2>
<p>Cet éditeur polyvalent a connu une version mineure corrective.</p>
<h2 id="emms-43-mai">
<a href="https://www.gnu.org/software/emms/">emms-4.3</a> (mai)</h2>
<p>Ce logiciel utilisé pour gérer les fichiers multimédia dans <em>emacs</em> reçoit quelques corrections, affiche plus de métadonnées à l’exécution et moins d’avertissements à la compilation.</p>
<h2 id="freedink-data-10820170409-avril">
<a href="https://www.gnu.org/software/freedink/">freedink-data-1.08.20170409</a> (avril)</h2>
<p>Les données de ce jeu d’aventure et de rôle à la Zelda sont complétées par deux nouveaux sons, une traduction en suédois et des mises à jour des traductions catalane, espagnole et allemande, ainsi qu’une construction reproductible.</p>
<p><img src="//img.linuxfr.org/img/68747470733a2f2f7777772e676e752e6f72672f736f6674776172652f6672656564696e6b2f73637265656e73686f74732f6672656564696e6b2d312e30385f323030382d30372d33315f7468756d626e61696c2e6a7067/freedink-1.08_2008-07-31_thumbnail.jpg" alt="Capture freedink" title="Source : https://www.gnu.org/software/freedink/screenshots/freedink-1.08_2008-07-31_thumbnail.jpg"></p>
<h2 id="gcc-710-mai">
<a href="https://www.gnu.org/software/gcc/gcc-7/changes.html">gcc-7.1.0</a> (mai)</h2>
<p>Cette suite de compilateurs <a href="//linuxfr.org/news/sortie-de-gcc-7">a ou aura sa propre dépêche pour détailler les nouveautés</a>.</p>
<h2 id="global-657-mai">
<a href="https://www.gnu.org/software/global/">global-6.5.7</a> (mai)</h2>
<p>Cet outil pour étiqueter du code source reçoit une nouvelle option <code>--nearness</code>, des nouveaux alias <code>GTAGSOBJDIR</code> et <code>GTAGSOBJDIRPREFIX</code>, une nouvelle commande <code>--print</code>, la prise en charge des espaces de noms et traits de PHP 5 et supérieur, et des corrections de bogues.</p>
<h2 id="gnubik-243-avril">
<a href="https://www.gnu.org/software/gnubik/">gnubik-2.4.3</a> (avril)</h2>
<p>Il s’agit d’une mise à jour des traductions et la correction de bogues mineurs pour ce jeu de puzzle de type Rubik’s cube.</p>
<p><img src="//img.linuxfr.org/img/68747470733a2f2f7777772e676e752e6f72672f736f6674776172652f676e7562696b2f667265657a652e706e67/freeze.png" alt="Capture gnubik" title="Source : https://www.gnu.org/software/gnubik/freeze.png"></p>
<h2 id="gnupg-2121-mai">
<a href="https://lists.gnupg.org/pipermail/gnupg-announce/2017q2/000405.html">gnupg-2.1.21</a> (mai)</h2>
<p>Cette suite d’outils autour d’OpenPGP corrige principalement un bogue important introduit par la version précédente, la suppression du squelette de configuration par défaut (remplacé par celui du système), l’installation sans être administrateur sous Windows et divers bogues.</p>
<h2 id="gnutls-3512-mai">
<a href="https://lists.gnupg.org/pipermail/gnutls-devel/2017-May/008427.html">gnutls-3.5.12</a> (mai)</h2>
<p>Cette bibliothèque pour gérer les protocoles SSL, TLS et DTLS connaît une version corrigeant divers bogues (sans changement d’<a href="https://fr.wikipedia.org/wiki/Interface_de_programmation">API</a> ou d’<a href="https://fr.wikipedia.org/wiki/Application_binary_interface">ABI</a>).</p>
<h2 id="grub-202-avril">
<a href="http://lists.gnu.org/archive/html/grub-devel/2017-04/msg00077.html">grub-2.02</a> (avril)</h2>
<p>La précédente version 2.00 de ce chargeur d’amorçage datait de 2012. Cette version apporte notamment des améliorations sur l’interface graphique et la prise en charge de nouvelles plates‐formes comme ARM, ARM64 et Xen, ainsi qu’une meilleure prise en charge de <a href="https://fr.wikipedia.org/wiki/Coreboot"><em>coreboot</em></a> (en pratique les distributions GNU/Linux utilisaient déjà des pré‐versions de la 2.02 depuis longtemps).<br><img src="//img.linuxfr.org/img/68747470733a2f2f68656c702e7562756e74752e636f6d2f636f6d6d756e6974792f47727562323f616374696f6e3d41747461636846696c6526646f3d676574267461726765743d67727562322e7468656d652e62656e6e6574742e706e67/Grub2?action=AttachFile&do=get&target=grub2.theme.bennett.png" alt="Exemple de thème tiré de la doc Ubuntu" title="Source : https://help.ubuntu.com/community/Grub2?action=AttachFile&do=get&target=grub2.theme.bennett.png"> (<a href="https://help.ubuntu.com/community/Grub2"><em>source</em></a> de l’image)</p>
<h2 id="guile-222-et221-avril">
<a href="https://www.gnu.org/software/guile/news/gnu-guile-222-released.html">guile-2.2.2</a> (et <a href="https://www.gnu.org/software/guile/news/gnu-guile-221-released.html">2.2.1</a>) (avril)</h2>
<p>Ce langage de programmation reçoit deux versions correctives (la dernière corrigeant la précédente). Citons notamment l’ajout d’une fonction de bac à sable pour tester du code d’utilisateurs inconnus et l’interdiction sous peine d’exception de modifier des constantes à la compilation ou à l’exécution.</p>
<h2 id="guile-cv-014-mai">
<a href="https://www.gnu.org/software/guile-cv/news.html">guile-cv-0.1.4</a> (mai)</h2>
<p>Il s’agit de la première version publique de cette bibliothèque de vision par ordinateur pour Guile Scheme, et première version incluse dans le projet GNU.</p>
<h2 id="guile-ncurses-22-avril">
<a href="https://www.gnu.org/software/guile-ncurses/">guile-ncurses-2.2</a> (avril)</h2>
<p>Cette bibliothèque <a href="https://fr.wikipedia.org/wiki/Ncurses"><em>ncurses</em></a> (interfaces textuelles) pour Guile vise la prise en charge de Guile 2.2.</p>
<h2 id="icecat-5202-gnu1-avril-et-5210-gnu1-mai"><a href="https://www.gnu.org/software/gnuzilla/">icecat-52.0.2-gnu1 (avril) et 52.1.0-gnu1 (mai)</a></h2>
<p>Il s’agit d’une version démarquée de Firefox, sans greffon ou extension non libre, qui suit donc les versions produites chez Mozilla.</p>
<h2 id="kawa-24-mai">
<a href="https://www.gnu.org/software/kawa/news.html">kawa-2.4</a> (mai)</h2>
<p><em>kawa</em> <a href="https://en.wikipedia.org/wiki/Kawa_%28Scheme_implementation%29">implémente du Scheme en Java</a>, et cette version est une corrective mineure.</p>
<h2 id="less-487-avril">
<a href="https://www.gnu.org/software/less/">less-487</a> (avril)</h2>
<p><em>less</em> permet de visualiser un fichier texte page par page. Cette version apporte des nouvelles commandes <code>ESC-{</code> et <code>ESC-}</code> pour aller au début et à la fin des lignes affichées, une mise en valeur des recherches qui gère l’option « sans tenir compte de la casse » <code>-i</code>, le passage à Unicode 9.0.0, une option <code>-Da</code> sous Windows pour le mode SGR et des corrections de bogues.</p>
<h2 id="libcdio-paranoia-1020941-avril">
<a href="https://www.gnu.org/software/libcdio/">libcdio-paranoia-10.2+0.94+1</a> (avril)</h2>
<p>Cette bibliothèque pour gérer les images CD (mais si, vous savez, les galettes en polycarbonate et alu) reçoit quelques corrections de bogues (la précédente version 10.2+0.93+1 datant de 2014).</p>
<h2 id="libidn2-201-avril-et202-mai"><a href="https://www.gnu.org/software/libidn/">libidn2-2.0.1 (avril) et 2.0.2 (mai)</a></h2>
<p>Cette bibliothèque gère le codage et le décodage des noms de domaine internationalisés suivant les spécifications IDNA 2008 et TR 46 (RFC <a href="https://tools.ietf.org/html/rfc5890">5890</a>, <a href="https://tools.ietf.org/html/rfc5891">5891</a>, <a href="https://tools.ietf.org/html/rfc5892">5892</a>, <a href="https://tools.ietf.org/html/rfc5893">5893</a> et <a href="http://www.unicode.org/reports/tr46/">TR 46</a>). Ces versions amènent la prise en charge de IDNA 2008 et TR 46 par défaut, et des corrections de bogues.</p>
<h2 id="libmicrohttpd-0953-avril-puis0954-et0955-mai"><a href="https://www.gnu.org/software/libmicrohttpd/">libmicrohttpd-0.9.53 (avril) puis 0.9.54 et 0.9.55 (mai)</a></h2>
<p>Cette bibliothèque qui évolue visiblement assez vite fournit un micro‐serveur Web en C. Ces versions amènent une meilleure prise en charge de l’en‐tête <code>Upgrade</code>, des options de compilation pour choisir la fonction de <em>polling</em> suivant la plate‐forme, et diverses corrections.</p>
<h2 id="linux-libre-41012-gnu-avril-et4112-gnu-mai"><a href="http://www.fsfla.org/ikiwiki/selibre/linux-libre/">linux-libre-4.10.12-gnu (avril) et 4.11.2-gnu (mai)</a></h2>
<p>Le <a href="http://www.fsfla.org/ikiwiki/selibre/linux-libre/">projet</a> vise à publier et maintenir le noyau Linux 100 % libre. Les principaux blocs binaires (<em>blobs</em>) sont présents dans les pilotes graphiques, mais aussi pour l’accélération cryptographique, l’Ethernet ou l’écran tactile, et chaque nouvelle version du noyau amène en général son lot de nouveaux blocs binaires.</p>
<h2 id="nano-281-avril-à284-mai"><a href="https://www.nano-editor.org/news.php">nano-2.8.1 (avril) à 2.8.4 (mai)</a></h2>
<p>L’éditeur de texte <em>nano</em> a connu quatre versions, notamment pour corriger des bogues, des plantages, améliorer les traductions, accélérer les recherches arrières, améliorer la coloration syntaxique en PHP, éviter d’introduire des blancs intempestifs, mieux gérer les caractères de largeur double, etc.</p>
<pre><code> ::: The
iLE88Dj. :jD88888Dj:
.LGitE888D.f8GjjjL8888E; .d8888b. 888b 888 888 888
iE :8888Et. .G8888. d88P Y88b 8888b 888 888 888
;i E888, ,8888, 888 888 88888b 888 888 888
D888, :8888: 888 888Y88b 888 888 888
D888, :8888: 888 88888 888 Y88b888 888 888
D888, :8888: 888 888 888 Y88888 888 888
D888, :8888: Y88b d88P 888 Y8888 Y88b. .d88P
888W, :8888: "Y8888P88 888 Y888 "Y88888P"
W88W, :8888:
W88W: :8888: 88888b. 8888b. 88888b. .d88b.
DGGD: :8888: 888 "88b "88b 888 "88b d88""88b
:8888: 888 888 .d888888 888 888 888 888
:W888: 888 888 888 888 888 888 Y88..88P
:8888: 888 888 "Y888888 888 888 "Y88P"
E888i
tW88D Text Editor Homepage
</code></pre>
<h2 id="ocrad-026-avril"><a href="http://lists.gnu.org/archive/html/bug-ocrad/2017-04/msg00000.html">ocrad-0.26 (avril)</a></h2>
<p>Ce logiciel de <a href="https://fr.wikipedia.org/wiki/Reconnaissance_optique_de_caract%C3%A8res">reconnaissance optique de caractères (OCR)</a> a connu une nouvelle version de pure maintenance (la dernière publication datant de 2015).</p>
<h2 id="orgadoc-09-mai"><a href="http://savannah.gnu.org/projects/orgadoc/">orgadoc-0.9 (mai)</a></h2>
<p>Le logiciel permet de copier et gérer un ensemble de documents sur plusieurs ordinateurs. La précédente version datait de 2004, et il s’agit surtout de mettre à jour les scripts et la documentation pour l’utilisation et l’installation.</p>
<h2 id="parallel-20170422-et20170522"><a href="https://www.gnu.org/software/parallel/">parallel-20170422 et 20170522</a></h2>
<p>Cet outil shell permet d’exécuter des tâches en parallèle sur un ou plusieurs ordinateurs. Ces versions sont nommées respectivement <em>Санкт-Петербу́рг</em> (Saint‐Pétersbourg) et <em>Macron</em> (les précédentes étant baptisées <em>TRAPPIST-1</em>, <em>13769</em> et <em>George Michael</em>). <em>Санкт‐Петербу́рг</em> abandonne la prise en charge de Perl 5.6 sur <a href="https://fr.wikipedia.org/wiki/IRIX" title="Définition Wikipédia">IRIX</a>, <code>--halt</code> prend désormais en charge <em>done</em> en plus de <em>success</em> et <em>fail</em>, et <em>parset</em> initialise les variables en Bash. Et <em>Macron</em> n’amène que peu de nouveautés (<code>--timeout</code> accepte <em>s=second</em>, <em>m=minute</em>, <em>h=hour</em> et <em>d=day</em>, tandis que l’alias <code>--dr</code> est ajouté pour <code>--dry-run</code>) et sert donc de version stable.</p>
<p><img src="//img.linuxfr.org/img/68747470733a2f2f7777772e676e752e6f72672f736f6674776172652f706172616c6c656c2f6c6f676f2d677261792b626c61636b3330302e706e67/logo-gray+black300.png" alt="Logo" title="Source : https://www.gnu.org/software/parallel/logo-gray+black300.png"></p>
<h2 id="conclusion">Conclusion</h2>
<p>Y a‐t‐il un intérêt à écrire une telle dépêche ? Bonne question, je vous remercie de l’avoir posée.</p>
<p>Pour <em>LinuxFr.org</em>, ça fait une dépêche publiée de plus, ce qui est plutôt bien (mais ça fait encore une longue dépêche diront certains, j’aurais dû en faire 33. ;)</p>
<p>Pour moi, ça m’a fait découvrir divers logiciels, donc j’ai trouvé ça plutôt intéressant, même si j’ai un peu de mal avec l’hétérogénéité du projet GNU, avec des annonces par courriel ou non, sur le site du projet ou non, dans les fichiers <code>Changelog</code> ou <code>NEWS</code> de l’archive, etc. Et probablement pas au point de la refaire tous les mois tout seul, parce que ça reste un poil long à rédiger. Des volontaires ?</p>
<p>Pour vous, je ne sais pas, mais si déjà vous lisez ça, c’est que vous êtes allés beaucoup plus loin que la plupart. Bravo, vous gagnez un niveau !</p>
<p>Ah oui, toute bonne conclusion doit terminer sur une ouverture : à voir les écarts de publication entre les versions, on peut se dire que le projet GNU manque de contributeurs (sur le code ou sur les sites des projets visiblement), qu’il est plus facile de pondre un nouveau logiciel que de le maintenir sur des dizaines d’années, qu’il s’attaque à des chantiers immenses (virer les <em>blobs</em>, par exemple). Ou plus positivement, on peut rester admiratif devant ces projets maintenus sur des dizaines d’années, ces très ambitieux projets lancés pour garantir les quatre libertés, la diversité des projets existants, la variété des langues prises en charge et le fait que des gens lisent une telle dépêche.</p></div><div><a href="https://linuxfr.org/news/nouvelles-versions-logicielles-du-projet-gnu-avril-et-mai-2017.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/112014/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/nouvelles-versions-logicielles-du-projet-gnu-avril-et-mai-2017#comments">ouvrir dans le navigateur</a>
</p>
Benoît SibaudDavy DefaudZeroHeureNils Ratusznikhttps://linuxfr.org/nodes/112014/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/370772017-01-06T20:00:39+01:002017-01-06T20:00:39+01:00Échanger des courriels avec Pôle-Emploi, ça peut être compliquéLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<p>Comme certains d'entre-vous le savent peut-être, depuis quelques mois, il n'est maintenant plus possible de prendre rendez-vous avec Pôle-Emploi en se présentant à leurs bureaux. Le moyen exclusif pour prendre rendez-vous avec son conseiller est de le contacter par courriel (du moins en Rhône-Alpes Auvergne).</p>
<p>Bon, j'aime bien avoir les gens en face par téléphone, pour être efficace et interagir rapidement sur les éventuelles raisons pour lesquelles je demande un rendez-vous, mais je peux m’accommoder d'un simple contact par courriel.</p>
<p>Problème, avec Pôle-Emploi et leur structure internet notoirement mal foutue, ça peut être plus compliqué qu'avec le reste du monde.</p>
<p>Je pose un peu la situation : j'utilise Alpine Linux, et <a href="https://pkgs.alpinelinux.org/packages?name=thunderbird&branch=&repo=&arch=&maintainer=">Thunderbird n'étant pas disponible dans leurs paquets précompilés</a>, je suis passé avec plaisir à Mutt, avec une configuration travaillée avec soin, très propre, qui me permet de signer avec GPG l'intégralité de mes courriels par défaut, au cas où, et avec toujours ma clé publique associée en pièce jointe.</p>
<p>C'est une pratique qui a permis de m'aider à faire que certains de mes correspondants habituels commencent eux aussi à chiffrer leurs courriels.</p>
<p>Et pour les échanges « officiels », j'utilise ma boîte Gmail, qui me permet de m'assurer à peu près que mes courriels seront mieux acceptés par les antispams que certains de mes serveurs perso'.</p>
<p>Une première fois, mon conseiller m'a envoyé un message. Manque de chance, leur système envoie toujours des messages formatés avec HTML. Ce n'avait jamais été un problème jusque là : le contenu des rares messages que je recevais ainsi formatés restaient lisible, malgré parfois un affichage légèrement dégradé.</p>
<p>Avec le courriel de Pôle-Emploi, tout simplement aucun contenu ne s'affichait. Bon, le problème a été rapidement résolu en installant w3m et deux lignes dans mon fichier muttrc.</p>
<p>Il y a deux mois, je réponds à mon conseiller, avec un message dûment signé.</p>
<p>J'attends une semaine, aucune réponse. Je relance. Une fois, deux fois, et finalement une dizaine de fois en presque deux mois, avec un ton de plus en plus agacé : j'ai besoin de toucher les allocations auxquelles j'ai pourtant droit, mais aucun moyen de relancer mon dossier. Aucun début de réponse.</p>
<p>Hier, je finis par repasser aux bureaux de Pôle-Emploi pour manifester mon mécontentement en face à face, malgré qu'il soit normalement impossible d'obtenir une entrevue avec un conseiller sans rendez-vous.</p>
<p>Par chance, on m'a redirigé tout de suite vers leur « responsable applicatif » (qui m'apprend que normalement les conseillers sont normalement contraints à répondre aux messages qui leurs sont envoyés dans les soixante-douze heures)), qui jette un coup d'œil à la boîte mail de mon conseiller attitré, et… surprise : aucun message ne lui est parvenu de ma part. Pas le moindre.</p>
<p>Il semblerait que les messages chiffrés ou avec des pièces jointes .asc soient simplement refusés.</p>
<p>Alors bon, qu'ils aient des mesures de « sécurité » de ce genre avec des pièces jointes dans des formats pas trop banals, pourquoi pas… Pour les courriels chiffrés, je trouve ça un peu con, mais je peux comprendre qu'ils ne prennent pas la peine de gérer une pratique un peu « exotique » (bien que standardisée) et qui ne concernent que quelques utilisateurs marginaux. Mais pourquoi pas.</p>
<p>Là où ça coince, en revanche, et où ça pose vraiment problème, c'est que les courriels sont refusés de manière parfaitement silencieuse : si j'avais reçu un courriel automatique de notification d'erreur, j'aurais pu corriger rapidement le problème sans souci. Même Mailman, par exemple gère ce genre de message d'erreur en cas de formats de pièces jointes non acceptées ou de messages trop lourds, et ça me semble vraiment la moindre des choses.</p>
<p>Là, leur système informatique un peu mal foutu a fini par créer de la frustration, de l'incompréhension et des problèmes financiers. Pour pas grand-chose.</p>
<p>Voilà, j'ai passé ma colère un trolldi, et au moins ça vous met au courant par avance si vous êtes un peu dans le même cas technique que moi.</p>
<p>Bonne soirée à vous, vous pouvez reprendre une activité normale. :)</p><div><a href="https://linuxfr.org/users/parleur/journaux/echanger-des-courriels-avec-pole-emploi-ca-peut-etre-complique.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/110984/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/parleur/journaux/echanger-des-courriels-avec-pole-emploi-ca-peut-etre-complique#comments">ouvrir dans le navigateur</a>
</p>
Parleurhttps://linuxfr.org/nodes/110984/comments.atomtag:linuxfr.org,2005:Diary/369832016-11-27T23:23:26+01:002016-11-27T23:23:26+01:00De la confiance dans le monde 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="#la-validit%C3%A9">La validité</a><ul>
<li><a href="#la-validit%C3%A9-dune-clef">La validité d’une clef</a></li>
<li><a href="#la-validit%C3%A9-dune-identit%C3%A9">La validité d’une identité</a></li>
<li><a href="#%C3%80-quoi-sert-la-validit%C3%A9">À quoi sert la validité ?</a></li>
<li><a href="#afficher-la-validit%C3%A9">Afficher la validité</a></li>
</ul>
</li>
<li><a href="#les-mod%C3%A8les-de-confiance">Les modèles de confiance</a></li>
<li>
<a href="#la-toile-de-confiance">La toile de confiance</a><ul>
<li>
<a href="#notion-de-certification">Notion de certification</a><ul>
<li><a href="#attributs-de-certification">Attributs de certification</a></li>
<li><a href="#notion-dauto-certification">Notion d’auto-certification</a></li>
</ul>
</li>
<li><a href="#notion-de-confiance">Notion de confiance</a></li>
<li><a href="#r%C3%A8gles-de-la-toile-de-confiance">Règles de la toile de confiance</a></li>
<li><a href="#un-exemple">Un exemple</a></li>
<li><a href="#cha%C3%AEne-de-certification-et-profondeur">Chaîne de certification et profondeur</a></li>
</ul>
</li>
<li>
<a href="#la-toile-de-confiance-%C3%A9tendue">La toile de confiance étendue</a><ul>
<li><a href="#notion-de-trust-signature">Notion de <em>trust signature</em></a></li>
<li><a href="#impact-des-trust-signatures">Impact des <em>trust signatures</em></a></li>
<li><a href="#limitation-du-champ-des-trust-signatures">Limitation du champ des <em>trust signatures</em></a></li>
</ul>
</li>
<li>
<a href="#le-mod%C3%A8le-trust-on-first-use">Le modèle <em>Trust On First Use</em></a><ul>
<li><a href="#pourquoi-un-nouveau-mod%C3%A8le-de-confiance">Pourquoi un nouveau modèle de confiance ?</a></li>
<li><a href="#principe">Principe</a></li>
<li><a href="#choix-de-la-politique-tofu-par-d%C3%A9faut">Choix de la politique TOFU par défaut</a></li>
<li><a href="#le-mod%C3%A8le-tofupgp">Le modèle TOFU+PGP</a></li>
</ul>
</li>
</ul><h2 id="introduction">Introduction</h2>
<p>La <em>confiance</em> est l’un des concepts à la fois les plus importants et les plus mal compris d’OpenPGP. Derrière ce terme peuvent se cacher en réalité deux notions bien distinctes, illustrées par les propositions suivantes :</p>
<ul>
<li>Alice est <em>confiante</em> que la clef 0xB4902A74 appartient à Bob ;</li>
<li>Alice <em>fait confiance</em> à Bob quand celui-ci lui dit que la clef 0x4B493BB7 appartient à Charlie.</li>
</ul><p>La première proposition fait référence à la <em>validité</em> de la clef 0xB4902A74, tandis que la seconde fait référence à la <em>confiance</em> proprement dite qu’Alice accorde à Bob.</p>
<blockquote>
<p><strong>Note</strong></p>
<p>Malheureusement, les auteurs et développeurs anglophones utilisent souvent le mot <em>trust</em> pour parler de la validité, et d’<em>ownertrust</em> pour parler de la confiance proprement dite, ce qui contribue probablement à la confusion entourant ces deux notions.</p>
</blockquote>
<p>Dans cet article, nous verrons ce que recouvrent précisément ces deux notions, comment elles interagissent, et comment les manipuler avec GnuPG.</p>
<p>Rappelons au préalable qu’une clef publique OpenPGP est, au minimum, l’association d’une <em>clef brute</em><sup id="fnref1"><a href="#fn1">1</a></sup> et d’une ou plusieurs <em>identités</em> (<em>User ID</em>) représentant le <em>propriétaire</em> de la clef (c’est-à-dire, celui qui possède ou contrôle la clef privée correspondante).</p>
<h2 id="la-validité">La validité</h2>
<p>On peut distinguer deux sortes de “validité” : la validite <em>d’une clef</em> et la validité <em>d’une identité</em>.</p>
<h3 id="la-validité-dune-clef">La validité d’une clef</h3>
<p>Une clef OpenPGP peut être</p>
<ul>
<li>
<em>révoquée</em>, si son propriétaire (ou un <em>révocateur désigné</em> mandaté par lui) a publié un <em>certificat de révocation</em> ;</li>
<li>
<em>expirée</em>, si la période de validité annoncée dans l’auto-signature la plus récente de la clef est dépassée.</li>
</ul><p>Dans les deux cas, la clef dans son ensemble est <em>invalide</em>. Cette invalidité est absolue : elle est intrinsèque à la clef et ne dépend d’aucun autre facteur (notamment, elle ne dépend pas de ce que peut penser un utilisateur donné).</p>
<p>Si la clef n’est ni révoquée ni expirée, alors sa validité est celle de la plus valide de ses identités.</p>
<h3 id="la-validité-dune-identité">La validité d’une identité</h3>
<p>La validité d’une identité d’une clef est une mesure de la certitude que l’on a que cette identité et cette clef sont bien associées, ou en d’autres termes, que la clef appartient bien au propriétaire désigné par l’identité.</p>
<p>Elle peut prendre plusieurs valeurs discrètes :</p>
<ul>
<li>
<strong>Invalide</strong> : Je suis sûr que la clef <em>n’*appartient *pas</em> à son propriétaire proclamé.</li>
<li>
<strong>Inconnue</strong> : Je n’ai aucune certitude quant à l’appartenance de la clef.</li>
<li>
<strong>Marginalement valide</strong> : J’ai des raisons de penser que la clef appartient bien à qui elle prétend sans pour autant en être sûr.</li>
<li>
<strong>Pleinement valide</strong> : Je suis sûr que la clef appartient bien à son propriétaire proclamé.</li>
</ul><p>Une identité n’est jamais valide ou invalide en elle-même : sa validité s’évalue toujours relativement à un utilisateur donné. Une même identité peut être pleinement valide pour une personne et à validité inconnue pour une autre, si ces deux personnes ont des certitudes différentes quant à l’appartenance de la clef.</p>
<p>Une identité peut aussi être <em>révoquée</em> par le propriétaire de la clef. Dans ce cas, l’identité est inconditionnellement invalide.</p>
<blockquote>
<p><strong>Note</strong></p>
<p>Il ne faut pas confondre la révocation d’une <em>clef</em> avec la révocation d’une <em>identité</em> : une clef révoquée est complètement inutilisable, tandis qu’une clef dont une des identités est révoquée reste utilisable tant qu’au moins une autre de ses identités n’est pas invalide.</p>
</blockquote>
<h3 id="À-quoi-sert-la-validité">À quoi sert la validité ?</h3>
<p>La validité répond à deux questions différentes selon que l’on veuille chiffrer un message ou vérifer une signature.</p>
<p>Lorsqu’on veut chiffrer un message, la validité définit si la clef du destinataire est utilisable, selon les règles suivantes :</p>
<ul>
<li>une clef expirée ou révoquée est inconditionnellement inutilisable<sup id="fnref2"><a href="#fn2">2</a></sup> ;</li>
<li>il est similairement impossible de chiffrer un message à destination d’une identité révoquée ou invalide ;</li>
<li>une confirmation sera demandée avant de pouvoir chiffrer un message à destination d’une identité dont la validité est inconnue ;</li>
<li>un avertissement sera affiché lors du chiffrement d’un message à destination d’une identité qui n’est que marginalement valide ;</li>
<li>seule une identité pleinement valide associée à une clef non-expirée et non-révoquée est utilisable sans condition ni avertissement.</li>
</ul><p>Lorsqu’on veut vérifier une signature, la validité de la clef signante définit le crédit que l’on peut accorder à la signature :</p>
<ul>
<li>si la clef est expirée, la signature n’est valable que si elle est antérieure à la date d’expiration ;</li>
<li>si la clef est révoquée parce qu’elle a été compromise, ou sans qu’une raison explicite ne soit donnée, la signature n’est pas valable ;</li>
<li>si la clef est révoquée mais que le certificat de révocation précise explicitement que la clef a été remplacée ou simplement retirée du service (c’est-à-dire, rien qui laisse supposer que la clef a été compromise), la signature est valable si elle est antérieure à la révocation ;</li>
<li>si la clef ne contient aucune identité pleinement valide, la signature reste valable, mais un message rappellera qu’il existe une incertitude sur le propriétaire de la clef et donc sur le signataire du message.</li>
</ul><h3 id="afficher-la-validité">Afficher la validité</h3>
<p>La commande <code>--list-keys</code> de GnuPG permet d’afficher la validité des identités d’une clef :</p>
<pre><code>alice$ gpg --list-keys bob
pub rsa2048 2015-06-05 [SC]
F336DF59EADFF278C40DBD7A21321A16B4902A74
uid [ full ] Robert <bob@example.com>
uid [ unknown] Bob du 92 <bob92@provider.example>
sub rsa2048 2015-06-05 [E]
</code></pre>
<p>Cette clef a deux identités associées : une pleinement valide (<em>full</em>), l’autre à validité inconnue (<em>unknown</em>).</p>
<blockquote>
<p><strong>Note</strong></p>
<p>Les versions de GnuPG antérieures à la 2.1 n’affichent pas, par défaut, la validité. Il faut ajouter l’option <code>--list-options show-uid-validity</code> sur la ligne de commande ou dans le fichier de configuration de GnuPG.</p>
</blockquote>
<p>La validité est également affichée dans l’éditeur de clef :</p>
<pre><code>alice$ gpg --edit-key bob
pub rsa2048/21321A16B4902A74
created: 2015-06-05 expires: never usage: SC
trust: marginal validity: full
sub rsa2048/E32EF7E899E238AD
created: 2015-06-05 expires: never usage: E
[ full ] (1). Robert <bob@example.com>
[ unknown] (2) Bob du 92 <bob92@provider.example>
</code></pre>
<p>En plus de la validité de chaque identité, l’éditeur de clef affiche aussi la validité de la clef dans son ensemble. Ici, la clef est complètement valide (<em>validity: full</em>), puisqu’elle n’est ni révoquée, ni expirée, et que l’une des deux identités associées est complètement valide.</p>
<p>Il n’y a pas de commande ou d’option pour <em>modifier</em> la validité. En effet — et c’est là le point central de cet article —, la validité d’une identité n’est pas décidée manuellement par l’utilisateur, mais déterminée automatiquement<sup id="fnref3"><a href="#fn3">3</a></sup> via un modèle de confiance.</p>
<h2 id="les-modèles-de-confiance">Les modèles de confiance</h2>
<p>Un <em>modèle de confiance</em> est un ensemble de règles permettant de déterminer la validité d’une identité. Formellement, on peut l’assimiler à une fonction associant à chaque identité, une valeur de validité parmi celles listées plus haut (inconnue, marginale, complète, ou invalide).</p>
<p>Une caractéristique distinctive d’OpenPGP, par rapport notamment à X.509/SMIME, est l’absence de modèle de confiance imposé ou même seulement défini par le standard. Ce n’est pas un oubli de la part des auteurs, mais bien au contraire une volonté affichée d’être le plus “générique” et de laisser les implémenteurs libres de développer les modèles de confiance de leur choix.<sup id="fnref4"><a href="#fn4">4</a></sup></p>
<p>Les modèles de confiance proposés par GnuPG (sélectionnables via l’option <code>--trust-model</code>) sont les suivants :</p>
<ul>
<li>la confiance systématique (<code>--trust-model always</code>) ;</li>
<li>la confiance directe (<code>--trust-model direct</code>) ;</li>
<li>la toile de confiance, en version “simple” (<code>--trust-model classic</code>) et en version “étendue”<sup id="fnref5"><a href="#fn5">5</a></sup> (<code>--trust-model pgp</code>) ;</li>
<li>le modèle <em>Trust On First Use</em>,<sup id="fnref6"><a href="#fn6">6</a></sup> utilisé seul (<code>--trust-model tofu</code>) ou conjointement avec la toile de confiance (<code>--trust-model tofu+pgp</code>).</li>
</ul><p>Le choix du modèle de confiance est une décision <em>locale</em> : chaque utilisateur peut utiliser le modèle qu’il préfère, sans incidence sur l’interopérabilité (deux personnes utilisant des modèles de confiance différents peuvent toujours communiquer).</p>
<p>Je ne m’étendrai pas sur les deux premiers modèles, qui sont les plus simples à comprendre mais qui sont aussi les moins utiles, sauf dans certaines conditions particulières.</p>
<p>Dans le modèle de “confiance systématique”, toutes les clefs sont toujours considérées pleinement valides.<sup id="fnref7"><a href="#fn7">7</a></sup> Ce modèle est de fait à éviter absolument dans le cas général des communications à travers l’Internet, où les fausses clefs ne sont pas rares. Il peut toutefois avoir un intérêt dans un environnement strictement contrôlé, dans lequel on peut être sûr qu’il ne circule que des clefs authentiques (mais a-t-on vraiment besoin d’OpenPGP dans un tel environnement ?).</p>
<p>À l’opposé, le modèle de “confiance directe” confie à l’utilisateur le soin de décider lui-même, directement, de la validité de chaque clef. C’est donc, par définition, une exception au principe énoncé plus haut selon lequel la validité est calculée automatiquement par le modèle de confiance et non assignée manuellement par l’utilisateur.</p>
<blockquote>
<p><strong>Note</strong></p>
<p>Ce modèle peut sembler attrayant, en particulier pour ceux que la complexité de la toile de confiance effraie. Néanmoins, les modèles plus récents de type TOFU, décrits plus loin, sont une meilleure alternative.</p>
</blockquote>
<p>Par défaut, GnuPG utilise le modèle <code>pgp</code>, la toile de confiance étendue.</p>
<h2 id="la-toile-de-confiance">La toile de confiance</h2>
<p>C’est <em>le</em> modèle de confiance traditionnellement associé à OpenPGP, au point d’en ignorer souvent que ce n’est qu’<em>un</em> des modèles possibles.</p>
<p>Il est, hélas, assez souvent mal compris et donc trop souvent mal utilisé.</p>
<p>La bonne compréhension de ce modèle nécessite d’introduire deux notions supplémentaires, qui étaient inutiles jusqu’à présent.</p>
<h3 id="notion-de-certification">Notion de certification</h3>
<p>Une <em>certification</em> est une signature sur le couple {clef brute, identité} (on parlera, très souvent, de <em>signature de clef</em>), par laquelle le signataire atteste (“certifie”) que cette clef brute et cette identité sont associées.</p>
<p>Formellement, l’ensemble formé d’une clef brute, d’une identité, et d’au moins une certification constitue un <em>certificat OpenPGP</em>. Ce terme est néanmoins rarement employé, l’usage ayant consacré l’expression <em>clef publique OpenPGP</em> à la place (entraînant hélas un risque de confusion avec le concept mathématique de clef publique, que je désigne dans ce document par <em>clef brute</em> justement pour éviter toute ambiguïté.).</p>
<h4 id="attributs-de-certification">Attributs de certification</h4>
<p>Une certification peut être qualifiée par plusieurs attributs, dont certains peuvent affecter l’interprétation qui doit être faite de cette certification.</p>
<p>Une certification est toujours qualifiée par un <em>niveau</em> (<em>certification level</em>) qui traduit la rigueur avec laquelle le signataire a vérifié l’identité du propriétaire de la clef. Le niveau 0 (certification “générique”) correspond à une absence d’engagement : en certifiant à ce niveau, le signataire ne donne délibérément aucune information. Le niveau 1 correspond en principe à une absence de vérification : en certifiant à ce niveau, le signataire annonce qu’il n’a pas particulièrement vérifié l’identité du propriétaire. En certifiant au niveau 2 ou au niveau 3, le signataire annonce qu’il a procédé à des vérifications plus rigoureuses.</p>
<blockquote>
<p><strong>Note</strong></p>
<p>Malheureusement, le standard OpenPGP ne définit pas précisément ce que peuvent être les vérifications pour chaque niveau. Chaque utilisateur peut ainsi donner à chaque niveau la signification de son choix, ce qui en pratique fait perdre beaucoup d’intérêt à la notion même de niveau de certification puisque deux utilisateurs peuvent avoir une opinion différente de ce qu’est une certification “rigoureuse”.</p>
<p>À titre d’exemple, je définis la limite entre les certifications de niveau 2 et 3 comme suit : si j’ai rencontré le propriétaire de la clef en personne, je certifie au niveau 2 ; s’il m’a en plus présenté une pièce d’identité officielle, je certifie au niveau 3. Mais ce n’est que <em>ma</em> politique : une certification de niveau 3 émise par un autre utilisateur peut avoir une signification différente.</p>
<p>En pratique, la plupart des certifications sont de niveau 0. C’est le niveau de certification par défaut avec GnuPG. Compte tenu de l’absence de signification universellement reconnue des différents niveaux de confiance, il est tout-à-fait raisonnable de s’en tenir à ce niveau 0 et d’ignorer jusqu’à l’existence même des niveaux supérieurs.</p>
</blockquote>
<p>Le signataire peut ajouter à sa certification une URL pointant vers un document supposé expliquer sa politique de signature (il peut notamment décrire la signification qu’il donne aux différents niveaux de certification). Cet attribut est purement informatif et à destination de l’utilisateur : GnuPG n’en fait aucun usage lui-même.</p>
<p>Une certification peut être marquée comme <em>locale</em>. Une telle certification n’est valable que dans le trousseau de celui qui l’a émise et sera automatiquement omise lorsque la clef sera exportée.</p>
<p>Enfin, une certification peut être marquée comme <em>irrévocable</em>. Normalement, toute certification peut être annulée (<em>révoquée</em>) <em>a posteriori</em> par son émetteur, simplement en publiant une signature de révocation (qui concrètement prend la même forme qu’une certification, c’est-à-dire une signature sur le couple {clef brute, identité}, mais signifie que toute certification antérieure sur le même couple, émise par la même clef, doit être considérée comme nulle). Si la certification initiale est marquée irrévocable, alors toute signature de révocation ultérieure sera ignorée.</p>
<h4 id="notion-dauto-certification">Notion d’auto-certification</h4>
<p>Chaque identité porte toujours au moins une <em>auto-certification</em>, c’est-à-dire une certification émise par la propre clef brute à laquelle l’identité est associée.</p>
<p>Si elle est sans valeur, comme on le verra, lors du calcul de la validité, elle permet surtout au propriétaire de la clef d’exprimer certaines préférences par l’intermédiaire d’attributs spécifiques aux auto-certifications :</p>
<ul>
<li>la durée de validité de la clef ;</li>
<li>un éventuel <em>révocateur désigné</em>, sous la forme de l’empreinte d’une clef tierce habilitée à émettre des certificats de révocation pour cette clef ;</li>
<li>les algorithmes de chiffrement, de condensation et de compression utilisables pour communiquer avec le propriétaire de cette clef, par ordre de préférence.</li>
</ul><p>Une fois émise, une (auto-)certification n’est pas modifiable. Pour changer l’un des attributs ci-dessus (par exemple pour repousser la date d’expiration de la clef, ou pour mettre à jour les algorithmes préférés), il faut émettre une nouvelle auto-certification, qui dans les faits annulera toute auto-certification antérieure. Seule l’auto-certification la plus récente est prise en compte quand il y en a plusieurs.</p>
<h3 id="notion-de-confiance">Notion de confiance</h3>
<p>La <em>confiance</em> proprement dite (<em>ownertrust</em>) est une valeur associée par l’utilisateur à une clef publique qui définit le crédit à accorder aux certifications émises par cette clef.</p>
<p>Comme pour la validité définie plus haut, la confiance peut prendre plusieurs valeurs discrètes :</p>
<ul>
<li>
<strong>aucune confiance</strong> : Ne jamais accorder aucun crédit aux certifications émises par cette clef.</li>
<li>
<strong>confiance inconnue ou indéterminée</strong> : Ignorer les certifications émises par cette clef.</li>
<li>
<strong>confiance marginale</strong> : Tenir compte des certifications seulement dans une certaine mesure (voir plus loin).</li>
<li>
<strong>confiance complète</strong> : Accorder toute leur valeur aux certifications.</li>
<li>
<strong>Confiance ultime</strong> : Valeur spéciale normalement réservée aux clefs “locales”, c’est-à-dire les clefs dont la partie privée est disponible.</li>
</ul><p>Dans le modèle de la toile de confiance simple, la confiance est toujours <em>explicitement assignée par l’utilisateur</em>. Chaque clef ajoutée au trousseau se voit assignée par défaut une confiance inconnue, et ce jusqu’à ce que l’utilisateur décide de la changer explicitement.</p>
<p>L’assignation de la confiance se fait via la commande <code>trust</code> de l’éditeur de clefs de GnuPG.</p>
<p>Dans l’exemple que nous avons vu plus haut, la clef de Bob, telle qu’elle figure dans le trousseau d’Alice, a une confiance marginale (<em>trust: marginal</em>).</p>
<h3 id="règles-de-la-toile-de-confiance">Règles de la toile de confiance</h3>
<p>On peut maintenant poser le principe de fonctionnement de la toile de confiance, telle qu’elle est implémentée par GnuPG.</p>
<p>Pour déterminer la validité d’une identité, on commence par retirer toutes les certifications <em>inexploitables</em> portées par cette identité. Précisément, on retire les certifications :</p>
<ul>
<li>émises par des clefs inconnues, c’est-à-dire qui ne figurent pas dans le trousseau local ;</li>
<li>émises par des clefs invalides ou à validité inconnue (ce qui élimine entre autres l’auto-certification émise par la clef même que l’on cherche à valider) ;</li>
<li>émises par des clefs révoquées ;</li>
<li>dont le niveau de certification est supérieur à zéro mais inférieur au paramètre <code>--min-cert-level</code> (qui vaut 2 par défaut, ce qui signifie que les certifications de niveau 1 sont ignorées) ;</li>
<li>révoquées par leur signataire, sauf si la certification initiale était marquée <em>non-révocable</em>.</li>
</ul><p>Pour chaque certification restante, on regarde ensuite la <em>confiance</em> assignée à la clef émettrice. S’il y a…</p>
<ul>
<li>au moins 1 certification émise par une clef à confiance ultime, l’identité est complètement valide ;</li>
<li>au moins <em>n</em> certifications émises par des clefs à confiance complète (avec <em>n = 1</em> par défaut, modifiable avec l’option <code>--completes-needed</code>), l’identité est complètement valide ;</li>
<li>au moins <em>m</em> certifications émises par des clefs à confiance marginale (avec <em>m = 3</em> par défaut, modifiable avec l’option <code>--marginals-needed</code>), l’identité est complètement valide ;</li>
<li>entre 1 et <em>n − 1</em> certification(s) émise(s) par des clefs à confiance complète, ou entre 1 et <em>m − 1</em> certification(s) émises par des clefs à confiance marginale, l’identité est marginalement valide ;</li>
<li>aucune certification émise par une clef à confiance au moins marginale, l’identité est à validité inconnue.</li>
</ul><h3 id="un-exemple">Un exemple</h3>
<p>Considérons un instant la clef d’Alice :</p>
<pre><code>alice$ gpg --list-keys alice
pub rsa4096 2015-06-05 [SC] [expires: 2018-06-04]
318D1F0158F237EB64797C0C5C5CE0D82EADF7D4
uid [ultimate] Alice <alice@example.org>
</code></pre>
<p>S’agissant d’une clef dont la partie privée est disponible (puisque nous sommes sur le système d’Alice), elle est intrinsèquement ultimement valide et de confiance.</p>
<blockquote>
<p><strong>Note</strong></p>
<p>Dans toutes les captures d’écrans qui suivent, pour gagner à la fois en place et en clarté, les <em>sous-clefs</em> seront systématiquement omises.</p>
</blockquote>
<p>Maintenant, imaginons qu’Alice vient juste d’obtenir la clef publique de Bob. Elle l’importe dans son trousseau et y jette un œil :</p>
<pre><code>alice$ gpg --import bob.asc
gpg: key 21321A16B4902A74: public key "Robert <bob@example.com>" imported
gpg: Total number processed: 1
gpg: imported: 1
alice$ gpg --list-keys --with-sig-check bob
gpg: 2 good signatures
pub rsa2048 2015-06-05 [SC]
F336DF59EADFF278C40DBD7A21321A16B4902A74
uid [ unknown] Robert <bob@example.com>
sig!3 21321A16B4902A74 2015-06-05 Robert <bob@example.com>
uid [ unknown] Bob du 92 <bob92@provider.example>
sig!3 21321A16B4902A74 2015-10-07 Robert <bob@example.com>
</code></pre>
<p>Cette clef a deux identités (<code>Robert <bob@example.com></code> et <code>Bob du 92 <bob92@provider.example></code>), chacune porteuse d’une auto-certification (émise par la clef 0xB4902A74, c’est-à-dire <em>cette</em> clef). En l’absence d’autres certifications, ces deux identités sont de validité inconnue.</p>
<p>Imaginons à présent qu’Alice est personnellement certaine qu’il s’agit bien de la clef de Bob (par exemple, Bob lui a confirmé l’empreinte de vive voix). Elle va donc certifier (signer) sa clef :</p>
<pre><code>alice$ gpg --edit-key bob
pub rsa2048/21321A16B4902A74
created: 2015-06-05 expires: never usage: SC
trust: unknown validity: unknown
[ unknown] (1). Robert <bob@example.com>
[ unknown] (2). Bob du 92 <bob92@provider.example>
</code></pre>
<p>Alice sélectionne la première identité, correspondant à la seule adresse de Bob dont elle soit sûre, puis la certifie :</p>
<pre><code>gpg> 1
pub rsa2048/21321A16B4902A74
created: 2015-06-05 expires: never usage: SC
trust: unknown validity: unknown
[ unknown] (1)* Robert <bob@example.com>
[ unknown] (2) Bob du 92 <bob92@provider.example>
gpg> sign
pub rsa2048/21321A16B4902A74
created: 2015-06-05 expires: never usage: SC
trust: unknown validity: unknown
Primary key fingerprint: F336 DF59 EADF F278 C40D BD7A 2132 1A16 B490 2A74
Robert <bob@example.com>
Are you sure that you want to sign this key with your
key "Alice <alice@example.org>" (5C5CE0D82EADF7D4)
Really sign? (y/N) y
gpg> save
</code></pre>
<blockquote>
<p><strong>Note</strong></p>
<p>Ici, en utilisant la commande <code>sign</code>, Alice a opté pour une signature « normale », sans fioritures : niveau de certification 0, exportable, révocable.</p>
</blockquote>
<p>Jetons à présent à nouveau un œil comme précédemment sur la clef de Bob :</p>
<pre><code>alice$ gpg --list-keys --with-sig-check bob
gpg: 3 good signatures
pub rsa2048 2015-06-05 [SC]
F336DF59EADFF278C40DBD7A21321A16B4902A74
uid [ full ] Robert <bob@example.com>
sig!3 21321A16B4902A74 2015-06-05 Robert <bob@example.com>
sig! 5C5CE0D82EADF7D4 2016-11-26 Alice <alice@example.org>
uid [ unknown] Bob du 92 <bob92@provider.example>
sig!3 21321A16B4902A74 2015-10-07 Robert <bob@example.com>
</code></pre>
<p>Si rien n’a changé pour l’identité « Bob du 92 » (qui n’a toujours que sa seule auto-certification et est donc toujours de validité inconnue), l’identité de « Robert », elle, porte désormais la certification d’Alice. La clef d’Alice étant de confiance ultime, cette identité est donc pleinement valide, en application des règles de la toile de confiance vues précédemment.</p>
<p>Remarquez qu’Alice n’a jamais directement modifié la validité de la clef de Bob. Je me permets d’insister parce que c’est la notion centrale de cet article : la validité est toujours <em>calculée</em> automatiquement par GnuPG, jamais directement assignée par l’utilisateur. <em>C’est en jouant sur la confiance que l’on affecte la validité</em>, selon des modalités qui varient selon le modèle de confiance utilisé.</p>
<p>Poursuivons l’exemple. Alice obtient à présent la clef de Charlie. Comme précédemment, elle l’importe et l’examine :</p>
<pre><code>alice$ gpg --import charlie.asc
gpg: key 3800CBA74B493BB7: public key "Charlie <charlie@example.net>" imported
gpg: Total number processed: 1
gpg: imported: 1
alice$ gpg --list-keys --with-sig-check charlie
gpg: 2 good signatures
pub rsa2048 2015-06-05 [SC]
3172310F9C0C11AEA1B057433800CBA74B493BB7
uid [ unknown] Charlie <charlie@example.net>
sig!3 3800CBA74B493BB7 2015-06-05 Charlie <charlie@example.net>
sig! 21321A16B4902A74 2016-11-26 Robert <bob@example.com>
</code></pre>
<p>La clef de Charlie n’a qu’une identité, laquelle porte deux certifications : l’auto-certification de rigueur, et une certification émise par Bob. Pourquoi cette identité est-elle considérée « de validité inconnue » ?</p>
<p>Parce que Alice n’a jamais assigné de valeur de confiance à la clef de Bob ! GnuPG lui a donc attribué, par défaut, une confiance inconnue, qui dans le modèle de la toile de confiance ne confère aucun crédit aux certifications émises par cette clef. Allons éditer la clef de Bob pour changer ça :</p>
<pre><code>alice$ gpg --edit-key bob
pub rsa2048/21321A16B4902A74
created: 2015-06-05 expires: never usage: SC
trust: unknown validity: full
sub rsa2048/E32EF7E899E238AD
created: 2015-06-05 expires: never usage: E
[ full ] (1). Robert <bob@example.com>
[ unknown] (2) Bob du 92 <bob92@provider.example>
gpg> trust
Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)
1 = I don't know or won't say
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
5 = I trust ultimately
m = back to the main menu
Your decision? 3
pub rsa2048/21321A16B4902A74
created: 2015-06-05 expires: never usage: SC
trust: marginal validity: full
sub rsa2048/E32EF7E899E238AD
created: 2015-06-05 expires: never usage: E
[ full ] (1). Robert <bob@example.com>
[ unknown] (1) Bob du 92 <bob92@provider.example>
Please note that the shown key validity is not necessarily correct
unless you restart the program.
gpg> quit
</code></pre>
<p>Alice a donc assigné une confiance marginale à la clef de Bob. Voyons ce que cela change sur la validité de la clef de Charlie :</p>
<pre><code>alice$ gpg --list-keys --with-sig-check charlie
gpg: 2 good signatures
pub rsa2048 2015-06-05 [SC]
3172310F9C0C11AEA1B057433800CBA74B493BB7
uid [marginal] Charlie <charlie@example.net>
sig!3 3800CBA74B493BB7 2015-06-05 Charlie <charlie@example.net>
sig! 21321A16B4902A74 2016-11-26 Robert <bob@example.com>
</code></pre>
<p>Avec une certification émise par une clef à confiance marginale, et avec les paramètres par défaut de la toile de confiance, la clef de Charlie est désormais marginalement valide.</p>
<h3 id="chaîne-de-certification-et-profondeur">Chaîne de certification et profondeur</h3>
<p>Le dernier exemple permet d’illustrer le concept de <em>chaîne de certification</em>, dont nous avons besoin pour expliquer une dernière règle du modèle de la toile de confiance, celle de la <em>profondeur maximale</em> de la chaîne de certification.</p>
<p>Dans cet exemple, Alice a certifié la clef de Bob, qui a lui-même certifié la clef de Charlie. Cette dernière se trouve ainsi à l’extrémité d’une chaîne remontant jusqu’à la clef d’Alice par l’intermédiaire de celle de Bob.</p>
<p>Comme nous regardons tout ceci depuis le point de vue d’Alice, sa clef est le point de départ de la chaîne. Elle est associée à une <em>profondeur</em> nulle. La clef de Bob, directement certifiée Alice, a une profondeur de 1 ; celle de Charlie, certifiée par Bob, a une profondeur de 2. Si Charlie certifiait la clef de David (et en supposant qu’Alice attribue une confiance explicite à la clef de Charlie, ce qu’elle n’a pas encore fait dans notre exemple), celle-ci aurait une profondeur de 3, et ainsi de suite.</p>
<p>La règle de la profondeur maximale dit simplement que la profondeur associée à une clef ne peut pas dépasser 5 (valeur par défaut, modifiable par l’option <code>--max-cert-depth</code>), ou autrement dit, qu’une chaîne de certification ne peut pas compter plus de 6 maillons.</p>
<p>Ainsi, si David certifiait la clef de Fanny qui elle-même certifiait la clef de Gordon qui lui-même certifiait la clef de Helen, cette dernière serait quoi qu’il arrive trop éloignée de la clef d’Alice (profondeur de 6) pour être considérée valide, même si Alice faisait explicitement confiance à David, Fanny et Gordon.</p>
<blockquote>
<p><strong>Note</strong></p>
<p>Dans les faits, il est extrêmement rare qu’une clef ne soit pas validée à cause de cette profondeur maximale. Les chaînes de certifications s’arrêtent généralement avant de heurter cette limite, par défaut de confiance explicite (plus on s’éloigne d’Alice, moins il y a de chance qu’elle connaisse suffisamment bien les personnes impliquées pour pouvoir assigner un niveau de confiance à leurs clefs).</p>
</blockquote>
<h2 id="la-toile-de-confiance-étendue">La toile de confiance étendue</h2>
<p>Jusque là, ce que nous avons vu était la toile de confiance <em>simple</em> (si, si…). Voyons à présent ce que recouvre la toile de confiance <em>étendue</em>.</p>
<p>La toile de confiance étendue fonctionne comme la toile de confiance simple, mais prend en compte un type particulier de certifications qu’on appelle les <em>trust signatures</em>.</p>
<blockquote>
<p><strong>Note</strong></p>
<p>La toile de confiance étendue est le modèle de confiance par défaut de GnuPG. Toutefois, si vous n’utilisez pas (et n’avez jamais émis) de <em>trust signatures</em>, alors dans les faits vous n’utilisez que la toile de confiance simple… comme la quasi-totalité des utilisateurs de GnuPG.</p>
</blockquote>
<h3 id="notion-de-trust-signature">Notion de <em>trust signature</em>
</h3>
<p>Une <em>trust signature</em> est semblable à une certification simple comme décrit plus haut (c’est-à-dire une signature sur un couple {clef brute, identité}), mais avec deux paramètres supplémentaires :</p>
<ul>
<li>une <em>profondeur</em> <em>n</em>, indiquant que la clef portant cette <em>trust signature</em> est habilitée à émettre elle-même des <em>trust signatures</em> de profondeur <em>n − 1</em> (une profondeur de zéro rend la <em>trust signature</em> strictement équivalente à une certification simple) ;</li>
<li>une <em>valeur de confiance</em> à assigner à la clef portant cette <em>trust signature</em> ; en principe cette valeur peut s’étendre de zéro à 255, mais en pratique il n’y a que deux possibilités : toute valeur inférieure à 120 est interprétée comme assignant une confiance marginale, et toute valeur supérieure ou égale à 120 est interprétée comme assignant une confiance complète.</li>
</ul><p>C’est dans ce second paramètre que réside la différence entre la toile de confiance simple et la toile de confiance étendue : les certifications de la toile de confiance simple ne servent qu’à déterminer la <em>validité</em> d’une identité, l’assignation de la confiance étant du seul ressort de l’utilisateur ; les <em>trust signatures</em> de la toile de confiance étendue déterminent à la fois la validité d’une identité <em>et</em> la confiance assignée à la clef associée.</p>
<h3 id="impact-des-trust-signatures">Impact des <em>trust signatures</em>
</h3>
<p>Pour illustrer l’impact des <em>trust signatures</em> sur la toile de confiance, reprenons à nouveau l’exemple d’une chaîne de certification allant de Alice à David en passant par Bob et Charlie.</p>
<p><img src="//img.linuxfr.org/img/68747470733a2f2f696e63656e702e6f72672f64766c70742f646f63732f776f742d636861696e732e737667/wot-chains.svg" alt="Fig1" title="Source : https://incenp.org/dvlpt/docs/wot-chains.svg"></p>
<p>En absence de <em>trust signatures</em>, du point de vue d’Alice seule la clef de Bob est valide (puisqu’elle est certifiée par une clef à confiance ultime, la sienne). Même si Bob a certifié la clef de Charlie, cette dernière restera à validité inconnue tant que Alice n’aura pas explicitement exprimé sa confiance envers Bob. (Il en va de même, <em>a fortiori</em>, pour la clef de David.)</p>
<p>Notez que chez lui, Bob fait peut-être confiance à Charlie, auquel cas la clef de David serait valide à ses yeux. Mais c’est sans intérêt pour Alice, qui n’a de toute façon aucun moyen de savoir quelle confiance Bob accorde à Charlie. Bob est le seul à savoir ça (même Charlie l’ignore) : dans la toile de confiance simple, la confiance est toujours une valeur <em>locale</em>, jamais partagée avec les autres membres de la toile.</p>
<p>Imaginons à présent que Alice a certifié la clef de Bob, non avec une certification simple, mais avec une <em>trust signature</em> de profondeur 2 et de confiance 120 : la clef de Bob est alors non seulement valide, mais se voit aussi <em>automatiquement</em> attribué une confiance complète. Si, de son côté, Bob a certifié la clef de Charlie avec une <em>trust signature</em> de profondeur 1 et de confiance 120, alors pour Alice, la clef de Charlie est valide et se voit aussi assigné <em>automatiquement</em> une confiance complète. Du coup, la clef de David, certifiée par Charlie, devient valide aux yeux d’Alice, même si elle ne s’est jamais prononcée elle-même sur la confiance à accorder à Charlie.</p>
<p>Notez que si Alice avait certifié la clef de Bob avec une certification simple, ou avec une <em>trust signature</em> de profondeur 1, la <em>trust signature</em> de Bob sur la clef de Charlie aurait été ignorée, ou plus exactement, traitée comme une certification simple, et aucune confiance n’aurait été automatiquement assignée à la clef de Charlie.</p>
<p>Cela signifie qu’il n’y a aucun risque d’utiliser la toile de confiance étendue par erreur. Même si tous les correspondants d’Alice émettaient des <em>trust signatures</em> à tout-va, celles-ci ne seront prises en compte par Alice que si elle décide elle-même d’entrer à son tour dans le jeu de la toile de confiance étendue, en émettant des <em>trust signatures</em> sur les clefs de ses correspondants. Si elle souhaite au contraire continuer à décider elle-même, seule, de la confiance à accorder à chacun, il lui suffit de ne jamais émettre que des certifications simples… ce que fait déjà GnuPG par défaut.</p>
<blockquote>
<p><strong>Note</strong></p>
<p>En pratique, <em>personne</em> n’émet de <em>trust signatures</em>. Sérieusement. En plus de dix ans d’utilisation de GnuPG, je n’en ai jamais vu une seule dans la nature. C’est pourquoi, bien que la toile de confiance étendue soit le modèle de confiance par défaut de GnuPG, dans les faits tout le monde utilise la toile de confiance <em>simple</em> (où les <em>trust signatures</em> peuvent exister mais sont traitées comme des certifications simples : leur valeur de confiance est ignorée, et elles ne servent qu’à calculer la <em>validité</em>).</p>
</blockquote>
<h3 id="limitation-du-champ-des-trust-signatures">Limitation du champ des <em>trust signatures</em>
</h3>
<p>Outre la profondeur et la valeur de confiance, une <em>trust signature</em> peut se voir adjoindre un troisième paramètre : une expression rationnelle qui limite les identités pour lesquelles la clef portant cette <em>trust signature</em> est autorisée à émettre elle-même des <em>trust signatures</em>.</p>
<p>Par exemple, imaginons que Alice certifie la clef de Bob avec une <em>trust signature</em> associée à l’expression rationnelle <code><[^>]+@example.net>$</code>. Dans ce cas, les <em>trust signatures</em> émises par Bob ne seront considérées comme légitimes que si elles sont appliquées sur des identités dont l’adresse e-mail est dans le domaine <code>example.net</code>. Si Bob certifie une identité <code>Charlie <charlie@nimportequoi.example></code>, sa certification sera ignorée.</p>
<p>Ce mécanisme est analogue à l’extension <em>Name Constraints</em> du monde X.509, qui limite les domaines pour lesquels une autorité de certification est habilitée à émettre des certificats.</p>
<blockquote>
<p><strong>Note</strong></p>
<p>L’implémentation de cette fonctionnalité dans GnuPG est plus restrictive que ne le permet le RFC 4880. GnuPG ne permet que d’exprimer une contrainte sur le domaine de l’adresse e-mail (comme dans l’exemple ci-dessus) ; il n’est pas possible de spécifier librement une expression rationnelle arbitraire.</p>
</blockquote>
<h2 id="le-modèle-trust-on-first-use">Le modèle <em>Trust On First Use</em>
</h2>
<h3 id="pourquoi-un-nouveau-modèle-de-confiance">Pourquoi un nouveau modèle de confiance ?</h3>
<p>Le modèle de confiance <em>Trust On First Use</em> (TOFU) a été introduit dans GnuPG 2.1.10, en décembre 2015. C’est la première introduction d’un nouveau modèle de confiance depuis les débuts de GnuPG.</p>
<p>La raison d’être de ce modèle part d’un constat qui ne surprendra guère les utilisateurs de GnuPG (ou de toute autre implémentation d’OpenPGP) : la toile de confiance est trop complexe à appréhender. Beaucoup d’utilisateurs (y compris parfois des utilisateurs de longue date) ne la comprennent pas réellement, ou ne comprennent pas toutes ses subtilités, et en conséquence ne l’utilisent pas correctement. Et même pour les connaisseurs, elle est souvent trop pénible à utiliser.</p>
<p>Le modèle de la « confiance à la première utilisation » est, sur le papier, moins « puissant » que la toile de confiance ; il est vulnérable, par définition, à une tentative d’usurpation lors du premier contact. <em>Mais</em> il est plus facile à appréhender et à utiliser. Il offre ce que certains auteurs anglophones appellent de la <em>better-than-nothing security</em>.</p>
<p>L’introduction de ce modèle de confiance (qui n’est pas encore le modèle par défaut — c’est toujours la toile de confiance étendue, pour l’instant — mais qui est appelé à le devenir) s’inscrit dans le cadre d’une ré-orientation des objectifs de GnuPG dans l’ère post-Snowden. Depuis ses débuts, GnuPG a été conçu pour répondre aux besoins d’utilisateurs faisant face à un niveau de menace élevé — le genre d’utilisateurs pour qui la difficulté d’accès du logiciel n’était pas forcément rédhibitoire, ou était un prix à payer acceptable. Désormais, à l’ère de la surveillance de masse, les développeurs de GnuPG considèrent que GnuPG doit être facile d’accès par défaut, pour les utilisateurs « ordinaires » souhaitant échapper à cette surveillance.<sup id="fnref8"><a href="#fn8">8</a></sup></p>
<blockquote>
<p><strong>Note</strong></p>
<p>L’idée n’est absolument pas de « castrer » GnuPG, de le rendre inutile à ceux qui font face à un niveau de menace élevé — notamment, ceux qui font face à des attaques ciblées et non pas à la simple surveillance de masse. C’est juste que, <em>par défaut</em>, GnuPG ne sera pas configuré pour eux.</p>
</blockquote>
<h3 id="principe">Principe</h3>
<p>GnuPG conserve une trace de toutes les associations {adresse e-mail, clef} qu’il rencontre (une telle association est appelée un <em>binding</em> dans la description du modèle), et associe à chacune d’elles une <em>politique TOFU</em>, parmi les cinq suivantes : <code>unknown</code>, <code>auto</code>, <code>good</code>, <code>bad</code>, et <code>ask</code>.</p>
<p>Chaque politique (à part la politique <code>ask</code>) correspond à une valeur possible de validité : <code>unknown</code> correspond à une validité inconnue, <code>auto</code> à une validité marginale, <code>good</code> à une validité complète, et <code>bad</code> correspond à une invalidité. Lorsque le modèle est interrogé pour déterminer la validité d’une identité, il renvoie la valeur de validité correspondant à la politique associé au <em>binding</em> concerné. (Si la politique est <code>ask</code>, GnuPG demande en direct à l’utilisateur ce qu’il doit faire avec cette clef.)</p>
<p>À la réception d’un premier message signé par <code>bob@example.com</code>, le <em>binding</em> {<code>bob@example.com</code>, 0xB4902A74} est ajouté à la base de données TOFU, associé à la politique par défaut qui est <code>auto</code>. Cela confère automatiquement une validité marginale à cette clef.</p>
<p>L’utilisateur peut à tout moment changer la politique associée à un <em>binding</em>. Par exemple, si Alice est sûre qu’il s’agit bien de la clef de Bob, elle peut lui assigner la politique <code>good</code>, conférant à sa clef une validité complète.<sup id="fnref9"><a href="#fn9">9</a></sup></p>
<p>À la réception d’un nouveau message de <code>bob@example.com</code>, GnuPG vérifie si la clef utilisée est la même que celle figurant dans le <em>binding</em> précédemment enregistré. Si c’est bien le cas, il n’y a pas de conflit, et GnuPG affiche que le message provient d’une clef marginalement valide. Si la clef est différente, l’utilisateur est alerté de l’existence d’un conflit.</p>
<h3 id="choix-de-la-politique-tofu-par-défaut">Choix de la politique TOFU par défaut</h3>
<p>La politique TOFU par défaut est celle appliquée implicitement lorsqu’un <em>binding</em> est ajouté à la base de données TOFU. Par défaut, cette politique par défaut est <code>auto</code> (comme on l’a vu ci-dessus), mais elle est modifiable avec l’option <code>--tofu-default-policy</code>. Et le choix de cette politique par défaut change profondément le comportement du modèle.</p>
<p>Trois politiques peuvent être définies comme la politique TOFU par défaut : <code>good</code>, <code>unknown</code>, et <code>auto</code>.</p>
<p>Avec <code>good</code> comme politique par défaut, on choisit un modèle « optimiste », dans lequel toute clef nouvellement rencontrée est implicitement considérée comme complètement valide. C’est en quelque sorte, le « vrai TOFU », le TOFU proprement dit.</p>
<p>À l’inverse, avec <code>unknown</code> comme politique par défaut, on choisit un modèle « pessimiste » voire « paranoïaque ». Il n’y a aucune validité implicite, toute clef nouvellement rencontrée est à validité inconnue et le reste jusqu’à ce que l’utilisateur assigne explicitement une politique <code>good</code> ou <code>auto</code>. C’est ce qui se rapproche le plus du modèle de confiance « directe » que j’avais rapidement abordé en présentant les différents modèles de confiance, avec en plus la détection des conflits.</p>
<p>Enfin, avec <code>auto</code> comme politique par défaut, on choisit un modèle intermédiaire, dans lequel toute clef nouvellement rencontrée est considérée comme marginalement valide.</p>
<h3 id="le-modèle-tofupgp">Le modèle TOFU+PGP</h3>
<p>Le modèle TOFU+PGP, comme son nom l’indique, est une combinaison du modèle de la toile de confiance étendue et du modèle TOFU.</p>
<p>Pour déterminer la validité d’une identité, les deux modèles sont interrogés successivement ; l’identité est valide si ① elle est valide dans au moins un des deux modèles, et ② elle n’est invalide dans aucun des deux modèles.</p>
<p>Ce modèle est particulièrement intéressant lorsque la politique TOFU par défaut est <code>unknown</code>. Dans ce cas, seule la toile de confiance assigne des valeurs de validité positives (validité marginale ou complète), et le modèle TOFU ne sert alors qu’à détecter les conflits.</p>
<div class="footnotes">
<hr>
<ol>
<li id="fn1">
<p>Traduction libre du terme anglais <em>key material</em>, désignant au sens strict la partie purement mathématique d’une clef cryptographique (par exemple, le couple {module, exposant} pour une clef RSA). Concrètement, c’est le contenu d’un paquet OpenPGP de type <a href="http://tools.ietf.org/html/rfc4880#section-5.5.1.1">Public-Key Packet</a>. <a href="#fnref1">↩</a></p>
</li>
<li id="fn2">
<p>Et GnuPG ne fournit aucun moyen de passer outre — même l’option <code>--expert</code>, qui autorise certaines actions normalement déconseillées, ne permet pas d’utiliser une clef expirée ou révoquée. <a href="#fnref2">↩</a></p>
</li>
<li id="fn3">
<p>C’est pourquoi on parle aussi parfois de <em>calculated trust</em> pour désigner la validité. <a href="#fnref3">↩</a></p>
</li>
<li id="fn4">
<p>Cette volonté apparaît à plusieurs reprises dans le standard OpenPGP. En fait, ce standard peut être compris comme une “PKI en kit”, un ensemble de briques permettant d’élaborer une infrastructure de clef publique, davantage que comme une infrastructure de clef publique prête à l’emploi. <a href="#fnref4">↩</a></p>
</li>
<li id="fn5">
<p>Les qualificatifs “simple” et “étendue” sont une invention de l’auteur, ils ne figurent pas dans les documentations de GnuPG. Nous verrons plus loin la différence entre les deux modèles. <a href="#fnref5">↩</a></p>
</li>
<li id="fn6">
<p>Introduit dans GnuPG 2.1.10, sorti en décembre 2015. <a href="#fnref6">↩</a></p>
</li>
<li id="fn7">
<p>Hors le cas des clefs <em>expirées</em> ou <em>révoquées</em>, qui sont toujours inconditionnellement invalides quel que soit le modèle de confiance. <a href="#fnref7">↩</a></p>
</li>
<li id="fn8">
<p>Werner Koch, développeur principal de GnuPG, a exprimé cette idée lors de la rencontre annuelle des développeurs Debian de 2015 (DebConf 2015). L’enregistrement de son intervention <a href="http://meetings-archive.debian.net/pub/debian-meetings/2015/debconf15/GnuPG_Past_Present_and_Future.webm">est disponible</a>, de même que <a href="https://gnupg.org/ftp/blurbs/debconf15_gnupg-past-present-future.pdf">ses diapositives</a>. <a href="#fnref8">↩</a></p>
</li>
<li id="fn9">
<p>Néanmoins, dans le modèle TOFU, la distinction entre la validité complète et la validité marginale est moins pertinente que dans le modèle de la toile de confiance, et Alice pourrait simplement laisser la politique par défaut. <a href="#fnref9">↩</a></p>
</li>
</ol>
</div><div><a href="https://linuxfr.org/users/gouttegd/journaux/de-la-confiance-dans-le-monde-openpgp.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/110636/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/gouttegd/journaux/de-la-confiance-dans-le-monde-openpgp#comments">ouvrir dans le navigateur</a>
</p>
gouttegdhttps://linuxfr.org/nodes/110636/comments.atom