gnupg: Obteniendo errores al intentar gpg --gen-key

He intentado eliminar mi directorio .gnupg pero el error regresa.

Entiendo esto:

gpg: lookup_hashtable failed: eof
gpg: lookup_hashtable failed: eof
gpg: upd_hashtable: read failed: eof
gpg: trust record 2, type 12: write failed: eof
gpg: Error: The trustdb is corrupted.
gpg: You may try to re-create the trustdb using the commands:
gpg:   cd ~/.gnupg
gpg:   gpg2 --export-ownertrust > otrust.tmp
gpg:   rm trustdb.gpg
gpg:   gpg2 --import-ownertrust < otrust.tmp
gpg: If that does not work, please consult the manual

Intenté seguir los consejos arrojados por el error y eso tampoco funciona. Intenté buscar en Google el problema pero no aparece nada para "lookup_hastable".

También instalé seahorse y tengo mis claves ssh almacenadas en seahorse. ¿Podría haber conflicto con el caballito de mar?

Me estoy ejecutando gpg --gen-keydesde mi cuenta de usuario normal y no intento hacer nada lujoso: solo cree una clave gpg estándar.

gpg gnupg

— bitofagoob
fuente

¿siguió las instrucciones del mensaje de error?

— Timothy Truckle el

¿Qué versión de GnuPG es esta? ¿Hay alguna instancia de gpg-agentejecución que interfiera y que deba ser eliminada?

— Kusalananda

Corregpg --fix-trustdb

— GAD3R

Tenía gpg-agent ejecutándose. Lo maté e intenté crear otra clave: el mismo problema. Luego borré mi directorio ~ / .gnupg y funciona. Voy a intentar reiniciar para ver si gpg-agent regresa para detenerme nuevamente. ¡Gracias!

— bitofagoob

gpg-agentse iniciará automáticamente al realizar operaciones clave con GnuPG 2.1, como debería hacerlo. El problema era que estaba usando dos versiones diferentes de GnuPG a la vez, o que algo más modificaba el contenido del .gnupgdirectorio de tal manera que gpg-agentse confundía. Al eliminar el .gnupgdirectorio, la ejecución gpg-agentno era consciente de ello. Esa es en gran medida un tipo de explicación que dice "agitar la mano".

— Kusalananda

Respuestas:

Me enfrenté a un problema similar con la falla de lookup_hashtable debido a su Unknown system errorlugar.

Supuse que sucedió después de importar una clave privada a través de gpg (y no gpg2) usando gpg --allow-secret-key-import --import private.key

Después de establecer el nivel de confianza después de esta publicación , el error desapareció.

— Vijay Agrawal
fuente

¡Gracias, ayudó! Creo que como parte de los comandos que está utilizando rm que falle si es interactivo "rm -i"

— Kumar

Yo tuve el mismo problema. Lo que es importante tener en cuenta es que hay dos versiones principales de GnuPG ('clásico' y 'estable', y también hay una 'moderna' 2.1): gpgy gpg2(en Fedora Core se proporcionan por paquetes gnupgy gnupg2respectivamente).

Busqué en Internet trustdbextensamente, eliminé ~/.gnupg, pero pude encontrar muy poca información y eso no ayudó.

Como en el repositorio de mi sistema operativo había una versión anterior gpg, descargué una 'moderna' gpgdel sitio oficial. Hubo un problema con libgrypt, necesitaba instalar una versión de biblioteca más nueva para gpgque funcione. Cuando lo hice manualmente, mi sistema se negó a arrancar. Creo que lo arreglaré pronto, pero ahora trabajo desde otra computadora portátil.

Finalmente me di cuenta de que hay un paquete gnupg2y usé el comando en gpg2lugar de gpg. Eso funcionó a la perfección. Puede establecer una fiesta alias gpg=gpg2en su .bash_profilesi desea olvidarse de los números.

— Yaroslav Nikitenko
fuente