Deux problèmes avec password-store et GnuPG
Pour gérer mes mots de passe, j’utilise l’excellent outil pass du projet password-store. Celui-ci utilise GnuPG pour chiffrer chaque mot de passe.
J’ai récemment changé de système d’exploitation (j’y reviendrai probablement en détails dans un prochain article) et je suis tombé sur deux problèmes avec ces deux outils. Comme j’ai mis un certain temps à trouver la cause et la solution à chacun de ces deux problèmes, je les partage ici si cela peut aider quelqu’un.
« Pas de clef secrète »
Le problème
Après avoir migré vers mon nouveau système d’exploitation et après avoir installé password-store, je demande un mot de passe et j’obtiens une erreur inquiétante :
$ pass show <nom du mot de passe> gpg: starting migration from earlier GnuPG versions gpg: porting secret keys from '/home/julien/.gnupg/secring.gpg' to gpg-agent gpg: migration succeeded gpg: échec du déchiffrement : Pas de clef secrète
Mon explication
En changement de système d’exploitation, je suis passé d’une version 1.x de GnuPG (version 1.4 ou 1.7) vers une version 2.x (version 2.2.12 exactement). Ma clé secrète a été automatiquement migrée. J’ai, pendant un long moment, pensé que le problème était lié à cette migration mais je pense qu’il n’en est rien.
L’erreur est en fait due au fait que gpg-agent, le démon lancé en arrière-plan par gpg pour gérer les clés secrètes, ne trouve pas de pinentry, ce petit utilitaire qui permet de taper le mot de passe associé à une clé secrète. Comme aucun mot de passe ne peut être saisi, le déchiffrement ne peut pas se faire.
Ma solution
J’ai d’abord installé un pinentry. Plusieurs sont disponibles mais j’ai choisi pinentry-gtk2 du projet GnuPG lui-même. La procédure dépend ici du système d’exploitation.
Ensuite, je me suis assuré que le pinentry installé soit bien trouvé par gpg-agent. Le chemin par défaut est indiqué dans la page de man de gpg-agent (man gpg-agent). Comme le chemin ne correspondait pas, j’ai configuré gpg-agent en créant un fichier ~/.gnupg/gpg-agent.conf avec le contenu suivant :
pinentry-program <chemin absolu du pinentry>
Enfin, j’ai tué le démon gpg-agent afin qu’il soit relancé avec la nouvelle configuration :
$ killall gpg-agent
J’ai relancé la commande pass ci-dessus et la boîte de dialogue du pinentry est bien apparue pour me demander mon mot de passe de clé secrète. Après saisie, le mot de passe désiré a bien été déchiffré.
« No public key »
Le problème
Cette fois, c’est lorsque j’ai essayé d’ajouter un mot de passe que j’ai obtenu une erreur :
$ pass insert <nom du mot de passe> Enter password for <nom du mot de passe>: Retype password for <nom du mot de passe>: XXX <xxx@domain.tld>: skipped: No public key gpg: [stdin]: encryption failed: No public key Password encryption aborted.
Mon explication
GnuPG ne retrouve pas la clé publique dont la référence est fournie par password-store. Cette référence se trouve dans le fichier ~/.password-store/.gpg-id. Dans mon cas, c’est l’alias de la clé (XXX <xxx@domain.tld>) qui y est indiqué. Cet alias contient un caractère français accentué. Je suspecte donc un problème de décodage de caractères, peut-être lié à l’absence de locales dans le système.
Ma solution
J’ai indiqué l’identifiant de la clé à password-store, au lieu de l’alias, afin d’éviter tout problème lié au codage de caractères.
Pour cela, j’ai d’abord listé les clés :
$ gpg --list-keys /home/julien/.gnupg/pubring.kbx ------------------------------- pub rsa2048 2013-08-23 [SC] 704B4670E3A941D56A1C57829AB0A8F0A73DDA4C uid [ inconnue] XXX <xxx@domain.tld> sub rsa2048 2013-08-23 [E]
Puis j’ai remplacé le contenu du fichier ~/.password-store/.gpg-id par l’identifiant de la clé (704B4670E3A941D56A1C57829AB0A8F0A73DDA4C).
J’ai relancé la commande pass ci-dessous et tout a fonctionné.
