Journal Bien démarrer avec GnuPG

Posté par (page perso) . Licence CC by-sa.
Tags :
70
21
mai
2020
Ce journal a été promu en dépêche : Bien démarrer avec GnuPG.

Sommaire

Suite à une diatribe de ma part à l’encontre de la mauvaise qualité de beaucoup de tutoriels consacrés à GnuPG, on m’a suggéré de créer le mien. Alors, without further ado, le voici.

Installation de GnuPG

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.

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).

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.

En 2020, il semble que sur la plupart des distributions GNU/Linux, demander l’installation d’un paquet gnupg installe bien GnuPG 2.2, le binaire correspondant étant disponible sous le nom gpg. Il y a quelques exceptions, comme par exemple Fedora, où gnupg installe GnuPG 1.4 — il faut demander l’installation de gnupg2 pour avoir GnuPG 2.2, le binaire correspondant étant appelé gpg2.

Dans le reste de cet article, je supposerai que gpg est le binaire de GnuPG 2.2 ; remplacez gpg par gpg2 si besoin en fonction de votre distribution.

Sous Windows, Gpg4Win 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.

Sous Mac OS X, GPG Suite est une distribution fournissant GnuPG 2.2.17. GnuPG est aussi disponible via MacPorts, sous le nom gnupg2.

Générer sa clef

É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.

Alors, une bonne fois pour toutes : générer une clef, ça se fait en une seule étape, une seule commande :

$ 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]

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. La configuration par défaut de GnuPG est saine ! 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 pourquoi ils ne conviendraient pas à votre cas d’utilisation — pas parce qu’un crypto-nerd vous dit de le faire dans son billet de blog « générer une clef parfaite en dix-sept étapes ».

À 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 :

  • pour le chiffrement : AES256, puis AES192, AES128, 3DES ;
  • pour la condensation : SHA2-512, puis SHA2-384, SHA2-256, SHA2-224, SHA-1 ;
  • pour la compression : ZLIB, puis BZIP2, ZIP, pas de compression.

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.

É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 GnuPG1 :

$ 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]

Vous obtenez alors une clef principale de signature de type ed25519 et une sous-clef de chiffrement de type cv25519 ; comme leur nom le laisse supposer, ces clefs sont basées sur la courbe elliptique dite « 25519 » (RFC 7748).

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 (RFC 6637). 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.

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.

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.

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 .

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.

Fig1
Figure 1. Les quatre étapes pour créer une clef avec GNU Privacy Assistant (GPA), le frontal officiel de GnuPG: saisissez votre nom (A), votre adresse e-mail (B), choisissez si vous voulez une copie de sauvegarde de votre future clef (C), observez votre clef nouvellement créée (D).

Que faire après avoir créé sa clef ?

Sauvegarder les clefs

Sauf contraintes très particulières, vos clefs doivent ê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.

S’il est possible d’adopter pour les clefs publiques une stratégie de sauvegarde torvaldienne (i.e. 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…

Vous pourriez être tenté de faire une simple archive du dossier .gnupg, 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).

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 :

$ gpg -o backup.gpg --export-secret-keys alice@example.org

Contrairement à ce que le nom de la commande --export-secret-keys peut laisser supposer, le fichier backup.gpg 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.

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 :

$ gpg -o public-keys.gpg --export
$ gpg --export-ownertrust > trust.txt

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.

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 !

Une option de sauvegarde que j’apprécie particulièrement et que je recommande est celle de la sauvegarde sur papier. L’outil Paperkey est spécialement conçu pour ça : donnez-lui votre copie de sauvegarde et il en fera une version imprimable :

$ paperkey --secret-key backup.gpg | lpr

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 :

$ gpg --import backup.gpg
$ gpg --import public-keys.gpg
$ gpg --import-ownertrust < trust.txt

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é frompaper.txt dans la commande ci-dessous), puis utilisez paperkey à nouveau pour reconstituer le fichier backup.gpg :

$ paperkey --pubring public-keys.gpg --secrets frompaper.txt --output backup.gpg

Notez l’utilisation du fichier public-keys.gpg, dans lequel paperkey vient trouver les parties publiques de votre clef (qui sont absentes de la version imprimable).

Mettre à l’abri le certificat de révocation

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.

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 :

gpg: revocation certificate stored as '/home/alice/.gnupg/openpgp-revocs.d/7685DC4214D727BB011BD6B754B4CC7749CAE7C3.rev'

Vous le trouverez donc le dossier .gnupg/openpgp-revocs.d, dans un fichier nommé d’après l’empreinte de votre clef.

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).

N’utilisez ce certificat de révocation que 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 ad hoc au moment où vous en avez besoin :

$ 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.

L’avantage d’un certificat de révocation ad hoc, 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, toutes les signatures jamais émises par la clef sont remises en cause (comme dans le cas où la clef a été compromise).

Pour utiliser un certificat de révocation, importez-le simplement dans votre trousseau avec gpg --import. Attention, importer un certificat de révocation ne demande pas de confirmation et est irréversible.

Diffuser la clef publique

Maintenant que vous avez une clef, il vous faut mettre la partie publique à disposition de vos correspondants.

Les serveurs de clefs SKS

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.

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 (SKS-Keyserver), 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é.2

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 sks-keyservers.net, contre facilement plus d’une centaine habituellement. Le réseau est toujours utilisable pour l’instant, mais il faut se préparer à ne plus pouvoir compter dessus dans un futur plus ou moins proche.

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 :

$ gpg --send-keys alice@example.org

Le serveur keys.openpgp.org

Un nouveau serveur de clefs a récemment vu le jour, en partie en réaction aux déboires du réseau SKS: keys.openpgp.org. Il utilise non pas SKS-Keyserver, mais Hagrid (le « gardien des clefs » de Poudlard), un serveur de clefs basé sur Sequoia-PGP (une bibliothèque OpenPGP en Rust).

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.

Il s’agit d’un 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 keys.openpgp.org est donc un single point of failure, et un single point of attack.

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.3

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 keys.openpgp.org.

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 ~/.gnupg/dirmngr.conf :

keyserver hkps://keys.openpgp.org

et de relancer le démon réseau de GnuPG, dirmngr :

$ gpgconf --reload dirmngr

Pour déposer une clef en revanche, la commande --send-keys 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 :

$ gpg -o alice.pub --export alice@example.org

puis télécharger le fichier alice.pub sur keys.openpgp.org/upload, et suivre les instructions d’Hagrid pour procéder à la vérification d’adresse.

Si vous utilisez le greffon Enigmail pour Thunderbird, il utilise déjà keys.openpgp.org 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.

Autres méthodes de distribution

D’autres méthodes existent pour assurer la diffusion des clefs publiques, notamment la publication dans le DNS (DANE, RFC 7929) et dans un Web Key Directory (WKD). Pour ces deux méthodes je vous renvoie à un précédent journal ; 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.

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.

Là où il n’est pas pratique de publier la clef proprement dite faute de place, n’hésitez pas à publier a minima 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.

Pour obtenir l’empreinte d’une clef (dont la vôtre), demandez simplement à GnuPG d’afficher ladite clef :

$ gpg -k alice@incenp.org
pub   rsa2048 2020-05-13 [SC]
      7685DC4214D727BB011BD6B754B4CC7749CAE7C3
uid           [ ultime ] Alice <alice@example.org>
sub   rsa2048 2020-05-13 [E]

Chiffrer, signer des fichiers

Cette section passe rapidement en revue la manière d’utiliser GnuPG sur des fichiers locaux, sans communication avec l‘extérieur.

Chiffrer un fichier

Pour chiffrer un fichier à votre propre intention, la commande de base est la suivante :

$ gpg -r alice@example.org -e lorem.txt

L’option -r UID (ou --recipient UID) indique la clef publique avec laquelle chiffrer le fichier. Elle attend en paramètre l’identité (UID, User ID) 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 -r alice 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).

Si vous prévoyez de chiffrer des fichiers à votre intention assez fréquemment, vous pouvez envisager d’ajouter l’option default-recipient-self dans le fichier de configuration de GnuPG (~/.gnupg/gpg.conf) ; 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 :

$ gpg -e lorem.txt

Le paramètre -e (ou --encrypt) est la commande de chiffrement. Elle attend simplement le nom du fichier à chiffrer, dans le cas présent lorem.txt. Cette commande produira un fichier lorem.txt.gpg, contenant la version chiffrée du fichier précédent.

Quelle que soit l’opération que vous demandez à GnuPG (chiffrer, signer, déchiffrer), vous pouvez toujours utiliser l’option -o (ou --output) pour spécifier explicitement le nom du fichier de sortie.

Signer un fichier

Il y a trois commandes différentes pour effectuer une signature, qui correspondent aux trois types de signature possibles.

  • La signature « standard » (faute d’un meilleur nom pour la désigner). Demandée avec la commande -s (ou --sign), elle produit un fichier contenant à la fois le document qui a été signé (enveloppé dans un paquet OpenPGP) et la signature correspondante.
  • La signature en clair (cleartext signature), avec la commande --clear-sign. 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.
  • La signature détachée, avec la commande -b (ou --detach-sign). Elle produit un fichier ne contenant que 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 ».

Il est possible de signer et chiffrer en même temps en combinant les commandes -s et -e. 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.

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 default-key UID1 dans le fichier de configuration de GnuPG pour toujours signer avec la clef associée à l’identité UID1, ou utiliser l’option -u UID2 sur la ligne de commande pour ponctuellement signer avec la clef associée à l’identité UID2.

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 :.gpg pour une signature normale, .asc pour une signature en clair, .sig 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.

Déchiffrer, vérifier un fichier

La commande -d (ou --decrypt) déchiffre un fichier :

$ 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
[...]

Notez l’asymétrie entre les commandes de chiffrement (-e) et de déchiffrement (-d) : la première produit un fichier, tandis que la seconde écrit par défaut sur la sortie standard.

Si le fichier lorem.txt.gpg é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 :

$ 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]

La commande -d, 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.

On utilisera la commande --verify pour vérifier une signature en clair…

$ 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]

… 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 .sig, mais il est préférable de spécifier le fichier explicitement) :

$ 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]

Il est aussi possible d’utiliser la commande --verify sur une signature « standard », mais dans ce cas, GnuPG ne fera que vérifier la signature, sans extraire le document signé contrairement à ce que fait la commande -d.

Fig2
Figure 2. Exemples d’opérations sur des fichiers avec GPA. Pour chiffrer et un fichier, ouvrez-le dans le File Manager (A) et cliquez sur le bouton correspondant dans la barre d’outils. Dans la fenêtre de dialogue qui s’ouvre (B), sélectionnez la clef publique avec laquelle chiffrer le document, et éventuellement la clef privée avec laquelle le signer. En (C), un exemple du résultat d’une vérification de signature.

Chiffrer, signer des e-mails

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.

Si vous n’avez pas d’amis, vous pouvez toujours envoyer un mail à Edward, un bot mis en place par la Free Software Foundation pour permettre aux gens d’essayer le chiffrement des e-mails.

Obtenir la clef d’Edward

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.

Cherchez donc la clef d’Edward sur les serveurs de clefs, et importez-là :

$ 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

Si vous avez choisi, dans la section relative aux serveurs de clefs, d’utiliser le nouveau serveur keys.openpgp.org, la clef d’Edward n’y est malheureusement pas disponible. Dans ce cas, vous pouvez utiliser l’option --keyserver sur la ligne de commande pour ponctuellement ignorer le serveur que vous avez configuré dans ~/.gnupg/dirmngr.conf :

$ gpg --keyserver hkp://pool.sks-keyservers.net --search-keys edward-fr@fsf.org

En cas de problème avec le réseau SKS, une copie de la clef est incluse ci-dessous :

-----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-----

Copiez-là dans un fichier puis importez-là manuellement :

$ gpg --import edward.asc

Une fois la clef d’Edward dans votre trousseau public, il faut la signer pour la marquer comme valide (je vous renvoie à un précédent journal 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 :

$ 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>
[…]

Affichez l’empreinte complète de la clef et vérifiez qu’elle correspond à l’empreinte dans la sortie ci-dessous :

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

Si l’empreinte correspond, vous pouvez procéder à la signature :

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

Thunderbird et Enigmail

Si vous utilisez le client e-mail Thunderbird, vous devez (pour l’instant) installer le greffon Enigmail 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.

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 prendra nativement en charge OpenPGP sans qu’un greffon ne soit nécessaire.

L’étendue de cette prise en charge native reste encore à voir, mais elle sera probablement, au moins dans l’immédiat, plus limitée que ce qui est actuellement offert par Enigmail.

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.

À 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 from scratch maintenant ? », comme par exemple avec le support des cartes OpenPGP.

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

Fig3
Figure 3. Utilisation d’Enigmail dans Thunderbird. (A) Sitôt installé, Enigmail détecte votre installation de GnuPG et vos clefs pré-existantes. (B) Envoi d’un e-mail chiffré et signé à Edward, auquel on joint une copie de sa propre clef publique. (C) Réception et déchiffrement de la réponse automatique d’Edward.

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 Apply my keys (Figure 3A).

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 p≡p plutôt que GnuPG. Sans rentrer dans les détails, p≡p 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 Junior mode, mais ce terme ne semble plus apparaître dans la documentation ou l’interface de Enigmail.

Vous pouvez maintenant envoyer un mail à edward-fr@fsf.org (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.

Lors de l’envoi, il se peut qu’Enigmail vous propose une option appelé protected headers, 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 proposition de standard à 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 pas chiffrés,4 et abstenez-vous de divlguer trop d’informations dans les objets de vos messages.

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.

(Neo)Mutt

Si vous utilisez le client Mutt ou le fork Neomutt, tous deux prennent nativement en charge OpenPGP et ne nécessitent qu’un minimum de configuration. Ajoutez simplement les deux lignes suivantes à votre fichier mutrc :

set crypt_use_gpgme = yes
set pgp_default_key = 0x7685DC4214D727BB011BD6B754B4CC7749CAE7C3

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 gpg directement (ce qui est toujours possible mais error-prone). 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.

Fig4
Figure 4. Utilisation de Neomutt. (A) Préparation d’un message chiffré et signé dans Neomutt. (B) 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é et signé. (C) Le menu de sélection de la clef publique du destinataire.

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 p pour appeler le menu PGP (Figure 4B) puis sur la touche b comme indiqué pour demander que le message soit chiffré et signé.

Attachez au message une copie de votre clef publique en tapant Esc-k 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 edward-fr@fsf.org), puis envoyez.

Attendez quelques minutes de recevoir la réponse d’Edward et vérifiez que tout s’est bien passé.

Autres clients

Il ne serait pas réaliste de vouloir couvrir tous les clients e-mail existants et je n’essayerai même pas.

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.

Sous Windows, la distribution Gpg4Win déjà mentionnée dans la première section est fournie avec GpgOL, un greffon pour Microsoft Outlook.

Sous Mac OS X, GPG Suite fournit un greffon pour Apple Mail appelé GPG Mail. Attention, ce greffon est libre (comme le reste de GPG Suite) mais, depuis peu, payant.

Sous Android, OpenKeychain apporte la prise en charge d’OpenPGP à plusieurs applications, dont le client de messagerie K-9 Mail.

À 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 Yubibey 5 NFC.


  1. 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. 

  2. 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. 

  3. L’intégrité des développeurs d’Hagrid et administrateurs de keys.openpgp.org 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. 

  4. 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. 

  • # Merci

    Posté par . Évalué à 7 (+7/-1).

    Super, merci!

    arnaud

    • [^] # Re: Merci

      Posté par . Évalué à 2 (+1/-0).

      Salut,

      Ouep, merci pour tout tes conseils !

      C'est super clair :)

      Éventuellement pour une prochaine, si tu fais une section "utilisateur avancé" (ce qui n'était clairement pas le but ici, donc voilà, je rajoute en commentaire), ssss permet de partager des petits secrets.

      Mais bon, je pense que tu connais ;)

      • [^] # Re: Merci

        Posté par (page perso) . Évalué à 7 (+5/-0).

        Je connais, oui, et j’ai déjà parlé de secret partagé dans un précédent journal.

        Quant à un prochain journal avec des notions plus « avancées », ça peut se faire en effet s’il y a de la demande.

        • [^] # Re: Merci

          Posté par . Évalué à 4 (+4/-0).

          Bonjour,

          Merci énormément d'avoir pris le temps d'écrire ce journal. J'attendais avec impatience les bons conseils pour générer ma clé.

          Voila qui est maintenant fait :-)

          La clé a donc une validité de deux ans.
          Que faire le 20/05/2022 pour pouvoir encore utiliser ma clé ?

          Peut-être un paragraphe pour le prochain journal ?

          • [^] # Re: Merci

            Posté par (page perso) . Évalué à 8 (+6/-0).

            Du coup ça me laisse deux ans pour répondre… tranquille, j’ai le temps. :)

            Il suffit de changer la date d’expiration, ce qui se fait avec la commande expire dans l’éditeur de clefs de GnuPG :

            $ gpg --edit-key alice
            La clef secrète est disponible.
            
            sec  rsa2048/54B4CC7749CAE7C3
                 créé : 2020-05-13  expire : 2022-05-13  utilisation : SC
                 confiance : ultime        validité : ultime
            ssb  rsa2048/45EDD81BCE62E9BD
                 créé : 2020-05-13  expire : 2022-05-13  utilisation : E
            [  ultime ] (1). 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.
                     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 : 2022-05-21  utilisation : E
            [  ultime ] (1). Alice <alice@example.org>

            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 expire après avoir sélectionné ladite sous-clef avec la commande key :

            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>
            

            La sous-clef de chiffrement est maintenant sélectionnée (notez l’astérisque ssb*), on peut changer sa date d’expiration :

            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
            

            À 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 tu te réveilles le 21 mai 2022 et que tu te rends comptes que tu as oublié de prolonger la période de validité de ta clef et qu’elle a expiré hier, il n’est pas trop tard pour la changer.

            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.

            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 1er janvier 1970 + 232 secondes ~= 7 février 2106). Mais si tu as besoin d’une clef valable aussi longtemps, autant rendre la clef inexpirable…

            • [^] # Re: Merci

              Posté par (page perso) . Évalué à 6 (+4/-0).

              J’oubliais un « léger » détail (qui peut sembler évident mais on ne sait jamais) : après avoir changé la date d’expiration d’une clef, il faut permettre à tes correspondants de prendre connaissance de la nouvelle date d’expiration, en re-publiant la clef via n’importe quel moyen a été utilisé pour la publier en premier lieu (par exemple, en la ré-envoyant vers un serveur de clefs avec --send-keys).

              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 ta machine tant que tu ne re-publies pas explicitement ta clef. À aucun moment GnuPG ne prendra l’initiative de transmettre tes modifications au monde extérieur.

              (Le changement de la phrase de passe ne nécessite évidemment pas de re-publication, puisque cela ne concerne que la clef privée.)

              • [^] # Re: Merci

                Posté par . Évalué à 2 (+1/-0).

                Salut,

                J'ai peut-être de mauvais réflexes, mais en général, je garde mes clefs, et quand il y a besoin d'une modification (tous les tremblements de terre, quoi), j'en recrée une autre que je signe avec la précédente.

                Je ne sais pas si c'est super bon comme pratique :/

                • [^] # Re: Merci

                  Posté par (page perso) . Évalué à 4 (+2/-0).

                  Bah ce n’est « ni bon ni mauvais », c’est juste qu’à mon avis tu te compliques inutilement la vie (tu dois conserver tes anciennes clefs) et tu compliques la vie de tes correspondants (qui doivent importer une nouvelle clef au lieu de simplement rafraîchir celle qu’ils ont déjà).

                  (Après ça dépend aussi de la fréquence à laquelle tu génère une nouvelle clef ; si tu fais ça une fois par moi, c’est vraiment se compliquer la vie ; une fois toutes les quelques années, c’est déjà plus raisonnable.)

                  Par contre si tu ne le fais pas déjà, je recommanderai de révoquer explicitement ton ancienne clef lorsque tu en créer une nouvelle. Sans ça tes correspondants après avoir importé ta nouvelle clef se retrouveront avec deux clefs à ton nom, toutes deux aussi valide l’une que l’autre. Non seulement c’est source de confusion, mais en plus tu n’as aucune garantie qu’ils utiliseront bien la nouvelle clef.

                  • [^] # Re: Merci

                    Posté par . Évalué à 1 (+0/-0).

                    Salut,

                    Euh oui, c'est plutôt genre tous les 5 ans on va dire grosso-modo, le renouvellement.

                    Du style : "Ok, y'a une faille vraiment importante, là, faut le faire".

                    Noté pour la révocation. :)

        • [^] # Re: Merci

          Posté par . Évalué à 3 (+2/-0). Dernière modification le 21/05/20 à 21:40.

          Salut,

          Clairement, je suis preneur d'un petit coup de "utilsation avancée" :)

          • [^] # Re: Merci

            Posté par . Évalué à 4 (+4/-0).

            Bonjour,

            un grand merci pour ce tutoriel.

            Je suis aussi preneur d'un tutoriel "avancé", notamment aussi l'utilisation des cartes à puce (smartcards) (openpgp) ou clefs usb.

            Avec la possibilité de se loguer avec la carte à puce (se loguer sur son desktop, ou à distance par ssh sur un serveur), par exemple, en plus du chiffrage/signature. En fait, la partie authentification.

            C'est d'ailleurs quelque chose que je n'ai jamais vraiment compris: comment se fait-il que ce ne soit pas inclus de base lors de l'installation d'un système.

            Eric

            • [^] # Re: Merci

              Posté par . Évalué à 3 (+3/-0).

              re-bonjour,

              je viens d'aller sur votre blog et des éléments de réponse à mes questions sont déjà traités!

              merci encore.

              Eric

            • [^] # Re: Merci

              Posté par (page perso) . Évalué à 5 (+3/-0).

              Avec la possibilité de se loguer avec la carte à puce (se loguer sur son desktop, ou à distance par ssh sur un serveur), par exemple, en plus du chiffrage/signature. En fait, la partie authentification.

              J’ai traité (presque tout1) ça il y a quelques années ici même. Certaines informations de cette dépêche sont maintenant obsolètes mais je maintiens une version à jour sur mon propre site.

              (De manière générale, presque tout ce que je publie sur DLFP est aussi disponible sur mon site.)


              1. Tout sauf l’utilisation d’un jeton OpenPGP pour s’authentifier sur son propre bureau. Il y a un module PAM pour ça appelé poldi, mais je ne l’ai jamais utilisé, puisque jusqu’à récemment Slackware ne fournissait pas PAM. 

              • [^] # Re: Merci

                Posté par . Évalué à 1 (+1/-0).

                re-bonjour

                cet article m'avait échappé …. grrrr!

                merci encore (dit-il plongé dans la lecture du journal).

                Je ne sais si c'est traité dans le journal, mais quelque chose que je cherche depuis un moment est la possibilité de "geler/dégeler/'changer de' une session" avec un lecteur NFC et soient des cartes, smartphone, bagues NFC)

                Je reviens après la lecture/étude de votre article.

                re-re-re merci

                Eric

  • # En avance sur le futur journal  « gpg avancé »

    Posté par . Évalué à 3 (+3/-0). Dernière modification le 22/05/20 à 09:48.

    Mercis à la pelle pour ce journal à la fois précis, solide, clair et bien écrit.

    Lorsque les terminaux se multiplient (machine pro, machine perso, autres machines persos, terminal sous Android, serveur genre YunoHost, ou que sais-je encore), la gestion des clés peut poser pas mal de questions, et obliger à des contorsions.

    C'est le cas même quand on n'a pas d'amis, par exemple si l'on confie (avec bonheur) la gestion de quelques dizaines de mots de passe à Pass, qui les chiffre avec gpg et les range dans un dépôt git. Ça suppose de pouvoir disposer des clés privées sur toutes les machines où l'on souhaite utiliser ces mots de passe.

    Pour ça, on peut choisir d'utiliser des sous-clés de signature et de chiffrement, et d'isoler la clé principale qui certifie ces sous-clés sur des supports chiffrés. Cette approche est décrite en d'innombrables endroits, par exemple ici.

    Que penser de cette approche?

    Par ailleurs, si l'on ne possède qu'un téléphone sans NFC, n'y a-t-il aucun compromis raisonnable pour utiliser OpenPGP avec icelui?

    • [^] # Re: En avance sur le futur journal  « gpg avancé »

      Posté par (page perso) . Évalué à 2 (+0/-0).

      Ça suppose de pouvoir disposer des clés privées sur toutes les machines où l'on souhaite utiliser ces mots de passe.

      Pour ça, la meilleure solution à mon sens, et de loin, est d’utiliser un jeton cryptographique (une carte OpenPGP, sous quelque forme que ce soit : une vraie carte à puce, une Yubikey, une Nitrokey, un Gnuk, etc.). Ça fait exactement le job, c’est sûr, et je m’avancerais à dire que c’est user-friendly — la seule barrière est financière, à part ça l’effort demandé à l’utilisateur est vraiment minimal.

      J’ai longtemps pensé que ces jetons étaient pour les « utilisateurs avancés », mais je n’en suis plus aussi sûr aujourd’hui. Et comme je vois que les géants du Net (Google and co.) n’hésitent pas à promouvoir des jetons physiques FIDO/U2F pour l’authentification à 2 facteurs, je me dis qu’on peut sans doute bien recommander un jeton physique OpenPGP aux utilisateurs de GnuPG, y compris à ceux qui débutent…

      Que penser de cette approche?

      Ce n’est pas nécessairement une mauvaise approche, mais j’aurais beaucoup plus de scrupules à la recommander à des débutants — surtout avec aussi peu d’explications que sur la page que tu cites.

      Par ailleurs, si l'on ne possède qu'un téléphone sans NFC, n'y a-t-il aucun compromis raisonnable pour utiliser OpenPGP avec icelui?

      Si le téléphone a un port USB-C, on peut utiliser une Yubikey 5C / 5Ci / 5C Nano.

      Sinon, si on parle de compromis il est toujours possible de choisir de faire suffisamment confiance à son téléphone pour y copier ses clefs privées. Pour ma part c’est niet (je crois que j’aurais encore davantage confiance en un PC sous Windows qu’en un smartphone, tout OS confondu…), mais c’est à chacun de voir.

  • # THanks for the fish but...

    Posté par (page perso) . Évalué à 1 (+6/-6).

    Honnêtement qui peut réellement prétendre se servir de GPG ? GPG, est avec XMPP, quelque chose de super sur le papier mais qui n'a jamais franchi le cercle très fermé des geeks. C'est le genre de bidule dont je perds la passphrase tous les 4 matins quand, par chance (malheur ?), un de mes contacts m'écrit avec sa signature (jamais reçu de message chiffré ici).

    C'est triste mais c'est vraiment une techno totalement hors de portée et je pense que rien ne pourra jamais rien y changer :/

    J'ai dû recevoir, genre, quoi, 3 messages chiffrés dans toute mon existence. Les messages signés arrivaient plus souvent mais, idem, les choses se sont calmées.

    Dommage.

    • [^] # Re: THanks for the fish but...

      Posté par (page perso) . Évalué à 4 (+1/-0).

      Il suffit d'avoir un compte Facebook, tu reçois tous les jours des mails chiffrés avec GPG.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: THanks for the fish but...

      Posté par (page perso) . Évalué à 2 (+0/-0).

      C'est le genre de bidule dont je perds la passphrase tous les 4 matins …

      C'est exactement pour ça que les gestionnaires de mots de passe existent. Tu ne retiens que la passphrase du gestionnaire (même principe que le mot de passe principal de Firefox).

      « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

      • [^] # Re: THanks for the fish but...

        Posté par (page perso) . Évalué à 1 (+0/-0).

        Oui mais non, les mots de passe je les garde bien en mémoire puisque je m'en sers régulièrement (CQFD) et si ce n'est pas le cas, c'est mon navigateur qui s'en charge pour moi :P

        • [^] # Re: THanks for the fish but...

          Posté par (page perso) . Évalué à 3 (+1/-0). Dernière modification le 23/05/20 à 16:32.

          Oui mais non. Je ne peux personnellement pas retenir ce type de mot de passe :
          Pb*kd*Z.w&^'#=!z7<R22QGg!>h\cY@0V"a&N<uoolE@1FSi\q0}D?v[/IUuCq'`

          Et toi ?

          « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

          • [^] # Re: THanks for the fish but...

            Posté par . Évalué à 2 (+1/-0).

            Moi ne je peux pas non plus.

            Je suis un adepte des phrases de passe. Une longue phrase absurde, et pas forcement correcte grammaticalement. Un peu comme de la poésie surréaliste.

    • [^] # Re: THanks for the fish but...

      Posté par (page perso) . Évalué à 6 (+4/-1).

      Oui, chaque fois que j'ajoute un paquet, que j'accède à mon gestionnaire de secrets, que j'utilise duplicity pour les sauvegardes, que je veux chiffrer rapidement un truc sur disque ou parfois pour du courriel. Au final, oui tous les jours.

      • [^] # Re: THanks for the fish but...

        Posté par (page perso) . Évalué à 2 (+4/-3).

        Donc c'est bien ce que je dis, c'est un truc pour les geeks et absolument pas pour 99% de la population ;)

        Qui fait des sauvegardes ? Le geek ou le mec de l'IT (peut être un utilisateur un peu averti).
        Qui chiffre ses fichiers ? Voir supra
        Gestionnaire de MDP, encore a la rigueur mais bon, les ¾ utilisent le même mot de passe pour tout
        et les autres stockent ça dans leur téléphone intelligent (dans le gestionnaire du tel ou ce genre de bidule qui demande un doit ou un oeil pour s'ouvrir)

        Non, vraiment, depuis le temps que ce truc existe, il n'a jamais pris en dehors des cercles de barbus technophiles.

      • [^] # Re: THanks for the fish but...

        Posté par (page perso) . Évalué à 0 (+1/-3).

        C’est que des cas qui ne nécessite absolument pas GPG.

        Les solutions que tu utilisent ont fait le choix de l’utiliser, ça veut pas dire que c’est nécessaire : tu pourrais signer tes paquets avec signify, utiliser Borg pour tes backups et KeepassX ou Bitwarden pour tes mots de passe.

        • [^] # Re: THanks for the fish but...

          Posté par (page perso) . Évalué à 10 (+12/-1).

          La question était « Honnêtement qui peut réellement prétendre se servir de GPG ? ». J'y ai répondu. Maintenant l'auteur de la question m'explique qu'il sous-entendait « à part les geeks barbus ». Et toi tu m'expliques que « C’est que des cas qui ne nécessite absolument pas GPG. » J'ai envie de vous dire de ne pas poser des questions si vous ne voulez pas écouter les réponses, ou si vous avez déjà vos préjugés et que les réponses sont inutiles. Quand bien je serais atypique et le dernier utilisateur de GPG dans l'univers, vos réponses sont à côté de la plaque.

        • [^] # Re: THanks for the fish but...

          Posté par (page perso) . Évalué à 5 (+3/-0).

          Ouais bon quand on lit la description de signify par son auteur

          There are no key servers for signify. No web of trust. Just keys. The good news is the keys are pretty small. As demonstrated. We can stick them just about everywhere, and we do. They're on the web site, they're on twitter, they're on the top side of CD. 56 base64 characters. You can read it out loud over the phone in under a minute. Wide dispersion makes it harder and harder to intercept all the ways you may get the key and increases the risk of detection should anybody try some funny business.

          Bon bah en fait c'est PGP sans le système de web of trust. Spoiler alert : à ce compte-là tu peux utiliser PGP pareil, en publiant ta clé et en espérant que les mediums de publication ne l'altèrent pas…

  • # Bien démarrer avec GnuPG

    Posté par (page perso) . Évalué à -6 (+4/-12).

    • Étape 1 : ne pas utiliser GPG/PGP ;
    • Étape 2 : investir dans d’autre solutions plus modernes (elles vont pas se faire toutes seule) :
    • Étape 3 : profiter.
    • [^] # Re: Bien démarrer avec GnuPG

      Posté par (page perso) . Évalué à -1 (+4/-6).

      Je ne suis pas loin de penser la même chose. C'est inutilisable pour le commun des mortels sans parler que tous les MUAs ne le proposent pas (et je ne parle même pas des webmails…).

      • [^] # Re: Bien démarrer avec GnuPG

        Posté par . Évalué à 9 (+7/-0).

        Il me semble que toutes les solutions « modernes » sont surtout moins fortes. Elles nécessites de faire confiance à une entité sur la quelle tu n'a aucun contrôle. Que ce soit utile pourquoi pas, mais il est nécessaire d'avoir une solution qui ne porte pas ces problèmes.

        De plus il faut remettre en contexte. Cette technologie que vous jugez désuète, vous vous appuyez probablement dessus. C'est un outil de travail nécessaire pour signer ses commits git et c'est ce que les gestionnaires de paquets utilisent pour vérifier les paquets avant installation par exemple. En parler comme d'un truc inutile, je trouve ça un peu rude.

        Je ne vois pas en quoi le fait que vous n'en voyez pas l'usage et que vous ne savez pas vous en servir en fait une technologie désuète ?

        • [^] # Re: Bien démarrer avec GnuPG

          Posté par (page perso) . Évalué à 1 (+3/-4).

          Il me semble que toutes les solutions « modernes » sont surtout moins fortes.

          J’ai plus facilement sécurisé mes communications en 3-5 ans avec Signal qu’en 10+ ans avec GPG/OpenPGP.

          C'est un outil de travail nécessaire pour signer ses commits git et c'est ce que les gestionnaires de paquets utilisent pour vérifier les paquets avant installation par exemple.

          Oui, mais on aurait probablement pas besoin de GPG/PGP pour faire ça.

          Par exemple, OpenBSD utilise signify.

          Je ne vois pas en quoi le fait que vous n'en voyez pas l'usage et que vous ne savez pas vous en servir en fait une technologie désuète ?

          Merci de t’inquiéter, mais je sais assez bien me servir de GPG et je comprends plutôt bien le fonctionnement d’OpenPGP, de la toile de confiance, etc.

          C’est fou, si on critique GPG c’est parce qu’on sais pas s’en servir ?

          • [^] # Re: Bien démarrer avec GnuPG

            Posté par (page perso) . Évalué à 3 (+2/-1). Dernière modification le 22/05/20 à 23:16.

            Étape 1 : ne pas utiliser GPG/PGP ;
            Étape 2 : investir dans d’autre solutions plus modernes (elles vont pas se faire toutes seule) :
            Étape 3 : profiter.

            Je ne vois pas en quoi le fait que vous n'en voyez pas l'usage et que vous ne savez pas vous en servir en fait une technologie désuète ?

            C’est fou, si on critique GPG c’est parce qu’on sais pas s’en servir ?

            Le problème est qu'il semble que vous confondez la coquetterie et^w^w^w les affirmations gratuites (et péremptoire) avec la critique (souvent jugée constructive).

            Adhérer à l'April, ça vous tente ?

      • [^] # Re: Bien démarrer avec GnuPG

        Posté par (page perso) . Évalué à 3 (+2/-1).

        J’ai complètement arrêté d’utiliser GPG pour les mails, principalement parce que c’est peine perdu d’essayer de sécuriser les mails et aussi parce que personne n’utilise réellement GPG dans mes cercles d’amis.

        J’utilise ProtonMail, mais c’est bien plus pour le chiffrement au repos (« at-rest ») que le chiffrement de bout en bout.

  • # E-mail sans support du client

    Posté par . Évalué à 2 (+1/-0).

    Merci pour cette introduction !

    Il arrive parfois d'être contraint d'utiliser un client qui ne supporte pas OpenPGP, ou une interface web à laquelle on ne fait que moyennement confiance. Est-il possible de chiffrer/déchiffrer/signer/vérifier un e-mail autrement, par exemple en copiant le contenu depuis/vers un fichier texte et en utilisant la ligne de commande ?

    • [^] # Re: E-mail sans support du client

      Posté par (page perso) . Évalué à 3 (+0/-0).

      Oui https://www.gnupg.org/gph/en/manual/x110.html

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: E-mail sans support du client

      Posté par (page perso) . Évalué à 3 (+1/-0).

      une interface web

      Pour les webmails, selon le webmail en question il est possible d’utiliser Mailvelope, une extension pour navigateur.

      (Je l’ai essayé une fois mais ne l’ai jamais intensivement testé, faute d’intérêt — je n’utilise pas de webmail.)

      Pour le cas plus général d’un client (web ou non) sans aucune prise en charge possible de OpenPGP, oui, il est toujours possible en dernier recours de procéder aux opérations de chiffrement/déchiffrement/signature à l’extérieur du client. GPA par exemple a un mode « clipboard », où tu peux écrire ton mail, le chiffrer et/ou le signer, puis copier le résultat vers ton client (et inversement, tu peux y copier un message chiffré que tu as reçu et l’y déchiffrer).

      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 webmail ne supporte pas OpenPGP, ce n’est pas surprenant, mais un client lourd, franchement pour moi c’est largement une raison suffisante pour le disqualifier d’office).

      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 parser des structures MIME « à la main ».

      • [^] # Re: E-mail sans support du client

        Posté par . Évalué à 4 (+2/-0).

        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 parser des structures MIME « à la main ».

        Je suis tombé il n'y a pas longtemps sur mime-construct qui est un script perl qui peut permettre de faire ça ; cf. le man qui indique à la fin explicitement une utilisation de GPG avec un document MIME.

        • [^] # Re: E-mail sans support du client

          Posté par (page perso) . Évalué à 3 (+1/-0).

          Je suis tombé il n'y a pas longtemps sur mime-construct qui est un script perl qui peut permettre de faire ça

          J’ai aussi commis un truc du même genre, quoique pas aussi générique.

          Une des raisons était de pouvoir envoyer des patchs par e-mail signés, ce que git send-email ne permet pas. Mon programme me permettait de faire ça :

          $ git format-patch ...
          $ fmail -s < 0001-mycommit.patch > 0001-mycommit.patch.signed
          $ git send-email 0001-mycommit.patch.signed

          (Mais c’était une mauvaise idée en fin de compte.)

          • [^] # Re: E-mail sans support du client

            Posté par . Évalué à 3 (+1/-0).

            (Mais c’était une mauvaise idée en fin de compte.)

            T'es fort pour nous laisser en suspend sur des problèmes intéressants… pourquoi, si c'est pas indiscret ? (ça n'est pas mentionné sur la page de fmail, ça pourrait être intéressant de l'expliquer pour l'histoire)

            • [^] # Re: E-mail sans support du client

              Posté par (page perso) . Évalué à 4 (+2/-0).

              pourquoi, si c'est pas indiscret ?

              En gros, parce que les listes de discussion ont des traditions douteuses qui persistent aujourd’hui et que Git a un support seulement minimaliste du format MIME.

              D’accord, j’explique.

              J’envoie des patchs sur une liste de discussion qui, comme (malheureusement) beaucoup de listes, juge utile de modifier les messages pour ajouter un footer contenant des informations sur la liste elle-même (typiquement un lien vers les archives de la liste sur le web, et un lien vers un formulaire de désinscription).

              C’est-à-dire que j’envoie un message constitué d’une seule part MIME (contenant le patch précédé du message de commit), et il est transformé par le logiciel de la liste de discussion en un message avec la structure suivante :

              • multipart/mixed (conteneur MIME)
                • text/plain (corps du message original, contenant le patch)
                • text/plain (« pied de page » de la liste de discussion)

              Pour l’instant, pas de problème : git am est capable de comprendre cette structure et d’extraire le patch de la part MIME qui le contient.

              Quand on signe un e-mail au format PGP/MIME, le mail résultant a la structure suivante :

              • multipart/signed (conteneur MIME)
                • text/plain (corps du message original)
                • application/pgp-signature (signature)

              Là encore, pas de problème pour l’instant, git am peut gérer ça.

              Le problème survient quand on envoie un tel message sur une liste de discussion qui rajoute un pied de page. Parce que là, le message final ressemble alors à ça :

              • multipart/mixed (conteneur MIME)
                • multipart/signed (conteneur MIME)
                • text/plain (corps du message original, contenant le patch)
                • application/pgp-signature (signature)
                • text/plain (pied de page de la liste de discussion)

              Et ça, c’est une structure que git am ne comprend pas et dont il est incapable d’extraire le patch. Du coup, ça casse le workflow du développeur upstream et augmente considérablement le risque que le patch ne soit purement et simplement ignoré.

              Le problème ne vient pas du message lui-même. Cette structure à plusieurs niveaux est une structure MIME parfaitement valide. C’est Git qui ne gère pas les conteneurs MIME imbriqués. Globalement, Git a un support très réduit de MIME, comme ses développeurs le reconnaissent ouvertement dans ce commentaire (mailinfo.c, lignes 213–216) :

              /* NOTE NOTE NOTE.  We do not claim we do full MIME.  We just attempt
               * to have enough heuristics to grok MIME encoded patches often found
               * on our mailing lists.  For example, we do not even treat header lines
               * case insensitively.
               */
              • [^] # Re: E-mail sans support du client

                Posté par . Évalué à 3 (+1/-0).

                Merci, c'est très intéressant. Je vais t'embêter encore un peu si ça ne te dérange pas (je comprendrais que tu n'aies pas le temps de répondre) : penses-tu qu'apprendre à git-am à traiter ce genre de message serait la bonne solution ? Enfin, ça ressemble plus à un hack qu'autre chose, mais d'un côté de ce que j'ai lu de la RFC 1847 on ne peut pas toucher à la structure multipart/signed donc on est obligé de « l'encapsuler » dans un multipart/mixed si on veut rajouter quelque-chose après.

                Bien sûr, la « bonne » solution serait de corriger les softs de gestion de ML pour qu'ils ne touchent pas les messages signés, mais je pense que c'est une bataille déjà perdue d'avance. Es-tu d'accord ?

                • [^] # Re: E-mail sans support du client

                  Posté par (page perso) . Évalué à 4 (+2/-0).

                  penses-tu qu'apprendre à git-am à traiter ce genre de message serait la bonne solution ?

                  Clairement, oui. Mais à mon avis il y a peu de chance que ça arrive. Le commentaire ci-dessus ne témoigne pas d’un très grand enthousiasme des développeurs de Git pour MIME…

                  Enfin, ça ressemble plus à un hack qu'autre chose

                  Pas vraiment, c’est une utilisation parfaitement légitime des conteneurs MIME.¹

                  Bien sûr, la « bonne » solution serait de corriger les softs de gestion de ML pour qu'ils ne touchent pas les messages signés, mais je pense que c'est une bataille déjà perdue d'avance.

                  Non. Les logiciels de liste de discussion peuvent déjà être configurés pour relayer les messages sans les modifier (par exemple, ne pas ajouter de pied de page, ou ne pas rajouter un préfixe [NOM_DE_LA_LISTE] dans le champ d’objet). Ce qu’il faudrait corriger, c’est l’opinion des administrateurs de listes qui pensent que de telles modifications sont des « fonctionnalités » incontournables des listes de discussion. Et ça, ça ne se corrige pas aussi facilement qu’un bug dans un logiciel. ^


                  ¹ À la décharge des développeurs de Git : ils ne sont pas les seuls à ne pas supporter les structures MIME complexes. Le format MIME autorise une grande complexité (on peut imbriquer les structures autant qu’on veut), mais beaucoup de clients e-mail ne supportent qu’un sous-ensemble des structures possibles.

                  • [^] # Re: E-mail sans support du client

                    Posté par (page perso) . Évalué à 3 (+0/-0).

                    Ce qu’il faudrait corriger, c’est l’opinion des administrateurs de listes qui pensent que de telles modifications sont des « fonctionnalités » incontournables des listes de discussion

                    Je ne suis pas d’accord. Si tu ne mets pas un lien « se désabonner » en haut, en bas et au milieu du mail, tu reçois 42 mails par jour d’utilisateurs pour se désabonner (et non, personne n’utilise List-Unsubscribe à par Google quand tu cliques sur Spam).

                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                    • [^] # Re: E-mail sans support du client

                      Posté par (page perso) . Évalué à 3 (+1/-0).

                      Fun fact : tu reçois aussi ces demandes de désabonnement sur les listes où le lien de désabonnement est ajouté à chaque message…

                      • [^] # Re: E-mail sans support du client

                        Posté par (page perso) . Évalué à 3 (+0/-0).

                        Oui, mais moins.

                        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                        • [^] # Re: E-mail sans support du client

                          Posté par (page perso) . Évalué à 2 (+0/-0).

                          Compte tenu de tous problèmes occasionnés par ces pratiques (pas seulement vis-vis de Git comme c’est le cas ici ; ces pratiques sont aussi une des raisons pour lesquelles DKIM et listes de discussion ne font pas toujours bon ménage), le bénéfice me semble minime.

                          Je suis pour ma part convaincu que ces pratiques subsistent davantage par conservatisme (« on a toujours fait comme ça ») que parce qu’elles ont une réelle utilité.

                          On peut agree to disagree sur ce point.

  • # Waouw !

    Posté par . Évalué à 2 (+1/-0).

    Merci beaucoup !

    Tu viens de créer je pense une référence francophone à l'utilisation de GNUPG.

    Le gros point noir, semble être le non-avenir de SKS, et la non-solution Hagrid…

    C'était tellement pratique d'utiliser SKS 😢

    "Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"

    • [^] # Re: Waouw !

      Posté par (page perso) . Évalué à 6 (+4/-0).

      C'était tellement pratique d'utiliser SKS

      Oui, et je pense d’ailleurs que c’est un des nœuds du problème. Le réseau SKS était bien pratique, tellement pratique qu’on était bien content de l’utiliser sans trop se poser de questions. En gros on le tenait pour acquis.

      Fun fact : à l’origine le serveur SKS n’était rien de plus qu’un exercice académique. Yaron Minsky faisait une thèse sur la meilleure façon de réconcilier des ensembles, il a écrit SKS comme une « preuve de concept » pour l’algorithme de réconciliation qu’il a inventé (les ensembles à réconcilier étant dans ce cas des trousseaux de clefs OpenPGP). Il n’avait jamais été prévu que SKS devienne un composant essentiel de la distribution des clefs OpenPGP…

      Le pire, c’est que j’ai l’impression qu’on est en train de refaire la même erreur avec keys.openpgp.org. Le serveur est très populaire et suscite un enthousiasme certain parmi les utilisateurs… qui sont bien content de l’utiliser sans trop se poser de question et sans se soucier de savoir si c’est une solution pérenne ou non.

      Je redoute personnellement que la disponibilité de keys.openpgp.org n’ait pour effet de couper court aux efforts visant à améliorer la distribution des clefs. Après tout pourquoi faire des efforts, on n’a qu’à dire à tout le monde d’utiliser keys.openpgp.org et puis voilà ! Une fois encore, on va confier la distribution des clefs à des bénévoles dont on tient le travail pour acquis.

      Par exemple, keys.openpgp.org permet à n’importe quel administrateur de domaine de supporter le protocole de distribution WKD simplement en redirigeant toutes les requêtes WKD sur ce domaine vers keys.openpgp.org (après avoir déposé les clefs du domaine sur le serveur, bien entendu). C’est sympathique, mais ça ne va pas motiver les administrateurs à mettre en place WKD eux-mêmes : pourquoi on se casserait la tête à prendre en charge la distribution des clefs des utilisateurs de notre domaine alors qu’en une ligne dans notre configuration DNS, on peut se décharger entièrement du problème vers les administrateurs de keys.openpgp.org ?

      WKD était supposé répartir la charge de la distribution des clefs (chaque domaine distribue ses propres clefs, ce qui à mon sens était raisonnable), mais l’offre de keys.openpgp.org risque d’aboutir à transformer WKD en un simple proxy vers un gros serveur centralisé… et les utilisateurs ne seront peut-être même pas conscients qu’ils utilisent un système centralisé.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.