gnupg: Ottenere errori nel tentativo di gpg --gen-key

Ho provato a cancellare la mia directory .gnupg ma l'errore ritorna.

Capisco questo:

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

Ho provato a seguire il consiglio emesso dall'errore e neanche quello ha funzionato. Ho provato a cercare su Google il problema ma non emerge nulla per "lookup_hastable".

Ho anche installato cavalluccio marino e ho le mie chiavi ssh memorizzate in cavalluccio marino. Potrebbe esserci un conflitto in corso con cavalluccio marino?

Sto correndo gpg --gen-keydal mio normale account utente e non sto cercando di fare nulla di speciale: basta creare una chiave gpg standard.

gpg gnupg

— bitofagoob
fonte

hai seguito le istruzioni dal messaggio di errore?

— Timothy Truckle,

Quale versione di GnuPG è questa? C'è un'istanza di gpg-agentcorsa che interferisce e che potrebbe aver bisogno di essere uccisa?

— Kusalananda

Eseguigpg --fix-trustdb

— GAD3R il

Avevo l'agente gpg in esecuzione. L'ho ucciso e ho provato a creare un'altra chiave: lo stesso problema. Quindi ho cancellato la mia directory ~ / .gnupg e funziona! Proverò a riavviare per vedere se gpg-agent ritorna per fermarmi di nuovo. Grazie!

— bitofagoob,

gpg-agentsi avvierà automaticamente quando si eseguono operazioni chiave con GnuPG 2.1, come dovrebbe fare. Il problema era che state usando due versioni diverse di GnuPG contemporaneamente o che qualcos'altro modificava il contenuto della .gnupgdirectory in modo tale da gpg-agentessere confuso. Durante l'eliminazione della .gnupgdirectory, l'esecuzione gpg-agentnon era a conoscenza di essa. Questo è molto un tipo di spiegazione "agitando la mano".

— Kusalananda

Risposte:

Ho riscontrato un problema simile con lookup_hashtable non riuscito a causa Unknown system errorinvece.

Ho pensato che fosse successo dopo aver importato una chiave privata tramite gpg (e non gpg2) usando gpg --allow-secret-key-import --import private.key

Dopo aver impostato il livello di attendibilità dopo questo post , l'errore era sparito.

— Vijay Agrawal
fonte

Grazie, mi ha aiutato! Penso che come parte dei comandi stia usando rm che fallisce se è interattivo "rm -i"

— kumar

Ho avuto lo stesso problema. Ciò che è importante rendersi conto è che ci sono due versioni principali di GnuPG ("classico" e "stabile", e anche un "moderno" 2.1): gpge gpg2(su Fedora Core sono fornite da pacchetti gnupge gnupg2rispettivamente).

Ho cercato su Internet trustdbampiamente, rimosso ~/.gnupg, ma sono riuscito a trovare pochissime informazioni e questo non ha aiutato.

Dato che nel mio repository OS c'era una versione precedente di gpg, ho scaricato un "moderno" gpgdal sito ufficiale. Si è verificato un problema con libgrypt, ho dovuto installare una versione di libreria più recente per gpgfunzionare. Quando l'ho fatto manualmente, il mio sistema ha rifiutato di avviarsi affatto. Penso che lo risolverò presto, ma ora lavoro da un altro laptop.

Alla fine ho capito che esiste un pacchetto gnupg2e ho usato il comando gpg2invece di gpg. Ha funzionato perfettamente. Puoi impostare una bash alias gpg=gpg2nel tuo .bash_profilese desideri dimenticare i numeri.

— Yaroslav Nikitenko
fonte