web-dev-qa-db-fra.com

Pourquoi gpg se fâche-t-il et comment puis-je l'arrêter?

J'ai récemment migré d'une installation d'Ubuntu à une autre et, ce faisant, j'ai changé mon nom d'utilisateur. J'ai importé ma paire de clés publique/privée dans gpg et, bien que le déchiffrement (à l'aide de ma clé privée) fonctionne correctement, chaque fois que j'essaie de chiffrer quelque chose avec ma clé publique, le message d'avertissement suivant s'affiche:

It is NOT certain that the key belongs to the person named
in the user ID.  If you *really* know what you are doing,
you may answer the next question with yes.

Après cela, il me demande si je veux vraiment utiliser la clé (je réponds toujours "oui", car il s’agit en fait de la clé seule de mon trousseau et je sais d’où il vient). Je peux déchiffrer les choses très bien, alors pourquoi gpg lance-t-il une crise à chaque fois que j'essaie de chiffrer quelque chose? Et comment puis-je empêcher ce message de réapparaître?

gnupg
23
fouric

J'ai réussi à reproduire le problème que vous rencontrez. Je l'ai fait comme suit:

$ gpg --no-default-keyring --keyring ./test-keyring  --secret-keyring ./test-secring --trustdb-name ./test-trustdb --no-random-seed-file --gen-key

<specified parameters and let it do its thing>

gpg: key 58018BFE marked as ultimately trusted
public and secret key created and signed.

<snip>

$

Notez que le processus a marqué la clé comme "finalement approuvée".

Maintenant j'exporte les clés:

$gpg --no-default-keyring --keyring ./test-keyring  --secret-keyring ./test-secring --trustdb-name ./test-trustdb --no-random-seed-file --export-secret-keys -a >private.key

$gpg --no-default-keyring --keyring ./test-keyring  --secret-keyring ./test-secring --trustdb-name ./test-trustdb --no-random-seed-file --export -a > public.key

Maintenant, j'importe dans une nouvelle base de données gpg:

$gpg --no-default-keyring --keyring ./test2-keyring  --secret-keyring ./test2-secring --trustdb-name ./test2-trustdb --no-random-seed-file --import public.key

$gpg --no-default-keyring --keyring ./test2-keyring  --secret-keyring ./test2-secring --trustdb-name ./test2-trustdb --no-random-seed-file --import private.key

Maintenant, si je tente de chiffrer en utilisant les nouveaux trousseaux de clés, je reçois:

$ gpg --no-default-keyring --keyring ./test2-keyring  --secret-keyring ./test2-secring --trustdb-name ./test2-trustdb --no-random-seed-file -r Fake -e
gpg: AE3034E1: There is no assurance this key belongs to the named user

pub  1024R/AE3034E1 2013-06-13 Fake User <[email protected]>
 Primary key fingerprint: AD4D BAFB 3960 6F9D 47C1  23BE B2E1 67A6 5801 8BFE
      Subkey fingerprint: 58F2 3669 B8BD 1DFC 8B12  096F 5D19 AB91 AE30 34E1

It is NOT certain that the key belongs to the person named
in the user ID.  If you *really* know what you are doing,
you may answer the next question with yes.

La raison en est le modèle du "réseau de confiance". Par défaut, pour qu'une clé publique soit approuvée, elle nécessite soit un certificat de confiance "ultime" (généralement lorsque vous avez personnellement vérifié l'identité des personnes impliquées), soit trois certificats de confiance "marginaux" (si vous connaissez quelqu'un, qui connaît quelqu'un que vous connaissez ... a signé le certificat).

Parce que gpg est une application de sécurité, il vous avertit si vous tentez de chiffrer une clé qui n'est pas répertoriée comme étant de confiance. La raison pour laquelle votre clé n'est pas fiable dans ce cas est simple. C'est parce que vous n'avez pas exporté les relations de confiance de l'instance précédente de gpg. Pour ce faire, utilisez les commandes --export-ownertrust et --import-ownertrust.

Comme toujours, reportez-vous à la page de manuel .

16
Garrett Kajmowicz

J'ai rencontré le même problème, mais je n'avais plus accès à l'ancienne clé. Ainsi, vous pouvez recréer la confiance sur votre ancienne clé avec ceci:

gpg --edit-key [email protected]
gpg> trust
Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)

  1 = I don't know or won't say
  2 = I do NOT trust
  3 = I trust marginally
  4 = I trust fully
  5 = I trust ultimately
  m = back to the main menu

Your decision? 5
Do you really want to set this key to ultimate trust? (y/N) y
26
Kevin Lyda

Vous pouvez utiliser l'indicateur --always-trust pour ignorer ce message.

7
Paul Baltescu