Le passage de la version par défaut de GnuPG de 1.4 à 2.1 est très important, et pourrait surprendre les utilisateurs de Debian Stable sur desktop (il y en a ?), alors quelques petites remarques sur ce qui change, pêle-mêle.
a) Là où GnuPG 1.x était monolithique (le binaire gpg faisait tout), GnuPG 2.1 a une architecture modulaire (déjà amorcée avec GnuPG 2.0, mais c’est vraiment la branche 2.1 qui a achevé cette transition), comprenant au minimum les composants suivants :
gpg, le programme principal ;
gpg-agent, l’agent de gestion des clefs privées ;
dirmngr, le démon réseau.
(On peut éventuellement y ajouter scdaemon, le démon d’accès aux cartes à puce, si vous utilisez ce genre d’outils.)
L’utilisation des démons auxiliaires est obligatoire (l’utilisation de gpg-agent était facultative avec GnuPG 1.x, ce n’est plus le cas avec GnuPG 2.x). Pas la peine de jouer avec l’option --no-use-agent, elle est silencieusement ignorée.
b) Les clefs privées sont désormais stockées dans le dossier $GNUPGHOME/private-keys-v1.d. Le fichier $GNUPGHOME/secring.gpg n’est plus utilisé. À la première utilisation de GnuPG 2.1, les clefs privées présentes dans secring.gpg seront silencieusement migrées vers private-keys-v1.d.
c) Tous les démons auxiliaires (gpg-agent, dirmngr, scdaemon) sont démarrés automatiquement quand ils sont nécessaires. Cela peut éventuellement surprendre ceux qui utilisaient précédemment GnuPG 2.0 (que Debian fournissait dans le paquet gnupg2), où un script /etc/X11/Xsession.d/90gpg-agent se chargeait de démarrer l’agent au démarrage d’une session.
Similairement, la variable d’environnement GPG_AGENT_INFO, précédemment utilisée pour localiser la socket de l’agent, n’a plus lieu d’être.
La socket en question, d’ailleurs, n’est plus placé dans $GNUPGHOME, mais dans /var/run/user/$(id -u)/gnupg, dossier qui est géré par Systemd. Vous n’avez normalement pas besoin de le savoir, mais ça peut occasionner des surprises voire des désagréments si vous aviez l’habitude de faire des choses un peu « exotiques » avec l’agent GnuPG (aeris devrait pouvoir vous en dire quelques mots — je crois qu’il s’est arraché quelques cheveux sur cette question).
d) Les clefs OpenPGP au format v3 (qui datent de l’époque de PGP 2.6, au milieu des années 1990) ne sont plus du tout prises en charge. Si vous avez encore des données qui traînent chiffrées avec une clef v3, vous aurez besoin de GnuPG 1.x (que Debian fournit désormais sous le nom gnupg1) — auquel cas je vous invite instamment à déchiffrer ces données et à les re-chiffrer avec une clef plus récente.
e) GnuPG 2.1 a introduit un nouveau format de stockage des clefs publiques, le format keybox (fichier $GNUPGHOME/pubring.kbx), plus efficace que l’ancien keyring (fichier $GNUPGHOME/pubring.gpg). Néanmoins, si vous avez déjà utilisé GnuPG ≤ 2.0 et que vous avez donc déjà un fichier pubring.gpg, GnuPG 2.1 continuera à utiliser le fichier existant. Pour migrer vers le nouveau format (ce qui n’est pas obligatoire, remarquez), l’approche recommandée est la suivante :
cd ~/.gnupg
# Exporter les valeurs de confiance
$ gpg --export-ownertrust > otrust.lst
# Renommer le trousseau publique (ancien format) pour qu’il ne soit plus reconnu par GnuPG
$ mv pubring.gpg publickeys
# Ré-importer les clefs publiques; en l’absence de pubring.gpg, GnuPG 2.1 créera automatiquement un fichier keybox
$ gpg --import-options import-local-sigs --import publickeys
# Ré-importer les valeurs de confiance
$ gpg --import-ownertrust otrust.lst
f) La procédure de génération de clefs a été simplifiée : GnuPG génère par défaut des clefs « standard » sans plus demander à l’utilisateur de choisir lui-même l’algorithme, la taille, la date d’expiration (la seule chose demandée est l’identité à associer à la clef). Utilisez la commande --full-gen-key au lieu de --gen-key pour retrouver l’ancienne procédure où vous pouvez spécifier vous-même les caractéristiques de la clef.
g) GnuPG 2.1 prend en charge la cryptographie elliptique, mais par défaut la création de clefs ECC n’est pas accessible, même en utilisant la commande --full-gen-key. Il faut ajouter l’option --expert pour se voir offrir la possibilité de créer une clef ECC.
# GnuPG 1.4 → 2.1
Posté par gouttegd . En réponse à la dépêche Debian 9 : Stretch déploie ses tentacules. Évalué à 10.
Le passage de la version par défaut de GnuPG de 1.4 à 2.1 est très important, et pourrait surprendre les utilisateurs de Debian Stable sur desktop (il y en a ?), alors quelques petites remarques sur ce qui change, pêle-mêle.
a) Là où GnuPG 1.x était monolithique (le binaire gpg faisait tout), GnuPG 2.1 a une architecture modulaire (déjà amorcée avec GnuPG 2.0, mais c’est vraiment la branche 2.1 qui a achevé cette transition), comprenant au minimum les composants suivants :
(On peut éventuellement y ajouter scdaemon, le démon d’accès aux cartes à puce, si vous utilisez ce genre d’outils.)
L’utilisation des démons auxiliaires est obligatoire (l’utilisation de gpg-agent était facultative avec GnuPG 1.x, ce n’est plus le cas avec GnuPG 2.x). Pas la peine de jouer avec l’option
--no-use-agent, elle est silencieusement ignorée.b) Les clefs privées sont désormais stockées dans le dossier
$GNUPGHOME/private-keys-v1.d. Le fichier$GNUPGHOME/secring.gpgn’est plus utilisé. À la première utilisation de GnuPG 2.1, les clefs privées présentes danssecring.gpgseront silencieusement migrées versprivate-keys-v1.d.c) Tous les démons auxiliaires (gpg-agent, dirmngr, scdaemon) sont démarrés automatiquement quand ils sont nécessaires. Cela peut éventuellement surprendre ceux qui utilisaient précédemment GnuPG 2.0 (que Debian fournissait dans le paquet gnupg2), où un script
/etc/X11/Xsession.d/90gpg-agentse chargeait de démarrer l’agent au démarrage d’une session.Similairement, la variable d’environnement
GPG_AGENT_INFO, précédemment utilisée pour localiser la socket de l’agent, n’a plus lieu d’être.La socket en question, d’ailleurs, n’est plus placé dans $GNUPGHOME, mais dans
/var/run/user/$(id -u)/gnupg, dossier qui est géré par Systemd. Vous n’avez normalement pas besoin de le savoir, mais ça peut occasionner des surprises voire des désagréments si vous aviez l’habitude de faire des choses un peu « exotiques » avec l’agent GnuPG (aeris devrait pouvoir vous en dire quelques mots — je crois qu’il s’est arraché quelques cheveux sur cette question).d) Les clefs OpenPGP au format v3 (qui datent de l’époque de PGP 2.6, au milieu des années 1990) ne sont plus du tout prises en charge. Si vous avez encore des données qui traînent chiffrées avec une clef v3, vous aurez besoin de GnuPG 1.x (que Debian fournit désormais sous le nom gnupg1) — auquel cas je vous invite instamment à déchiffrer ces données et à les re-chiffrer avec une clef plus récente.
e) GnuPG 2.1 a introduit un nouveau format de stockage des clefs publiques, le format keybox (fichier
$GNUPGHOME/pubring.kbx), plus efficace que l’ancien keyring (fichier$GNUPGHOME/pubring.gpg). Néanmoins, si vous avez déjà utilisé GnuPG ≤ 2.0 et que vous avez donc déjà un fichierpubring.gpg, GnuPG 2.1 continuera à utiliser le fichier existant. Pour migrer vers le nouveau format (ce qui n’est pas obligatoire, remarquez), l’approche recommandée est la suivante :f) La procédure de génération de clefs a été simplifiée : GnuPG génère par défaut des clefs « standard » sans plus demander à l’utilisateur de choisir lui-même l’algorithme, la taille, la date d’expiration (la seule chose demandée est l’identité à associer à la clef). Utilisez la commande
--full-gen-keyau lieu de--gen-keypour retrouver l’ancienne procédure où vous pouvez spécifier vous-même les caractéristiques de la clef.g) GnuPG 2.1 prend en charge la cryptographie elliptique, mais par défaut la création de clefs ECC n’est pas accessible, même en utilisant la commande
--full-gen-key. Il faut ajouter l’option--expertpour se voir offrir la possibilité de créer une clef ECC.