[gentoo-user] dirmngr crashes when launching Gnupg Log Viewer in Kleopatra
Mick
describe how I came across them:
1st Bug
Recently I tried to import a personal SSL certificate from Comodo into
Kleopatra version 2.0.9. Every time it fails when I enter a passphrase to
import it. Converting the .pkcs12 certificate and key file into a .pem format
and then trying to import that also fails with a "BER error".
The Gnupg Log Viewer shows:
===========================================================
[2010-05-07T22:24:22] Log cleared
[client at fd 4 connected]
4 - 2010-05-07 22:24:25 gpgsm[14692]: enabled debug flags: assuan
4 - 2010-05-07 22:24:25 gpgsm[14692.0] DBG: -> # Home: ~/.gnupg
4 - 2010-05-07 22:24:25 gpgsm[14692.0] DBG: -> # Config:
/home/michael/.gnupg/gpgsm.conf
4 - 2010-05-07 22:24:25 gpgsm[14692.0] DBG: -> # AgentInfo: /tmp/gpg-
yRFiu9/S.gpg-agent:13728:1
4 - 2010-05-07 22:24:25 gpgsm[14692.0] DBG: -> # DirmngrInfo: [not set]
4 - 2010-05-07 22:24:25 gpgsm[14692.0] DBG: -> OK GNU Privacy Guard's S/M
server 2.0.14 ready
4 - 2010-05-07 22:24:25 gpgsm[14692.0] DBG: <- OPTION display=:0.0
4 - 2010-05-07 22:24:25 gpgsm[14692.0] DBG: -> OK
4 - 2010-05-07 22:24:25 gpgsm[14692.0] DBG: <- OPTION enable-audit-log=1
4 - 2010-05-07 22:24:25 gpgsm[14692.0] DBG: -> OK
4 - 2010-05-07 22:24:25 gpgsm[14692.0] DBG: <- INPUT FD=21
4 - 2010-05-07 22:24:25 gpgsm[14692.0] DBG: -> OK
4 - 2010-05-07 22:24:25 gpgsm[14692.0] DBG: <- IMPORT
4 - 2010-05-07 22:24:25 gpgsm[14692]: invalid radix64 character 2d skipped
4 - 2010-05-07 22:24:25 gpgsm[14692]: invalid radix64 character 3a skipped
4 - 2010-05-07 22:24:25 gpgsm[14692]: invalid radix64 character 2c skipped
4 - 2010-05-07 22:24:25 gpgsm[14692]: invalid radix64 character 2d skipped
4 - 2010-05-07 22:24:25 gpgsm[14692]: invalid radix64 character 3a skipped
4 - 2010-05-07 22:24:25 gpgsm[14692]: invalid radix64 character 2d skipped
4 - 2010-05-07 22:24:25 gpgsm[14692]: total number processed: 0
4 - 2010-05-07 22:24:25 gpgsm[14692.0] DBG: -> S IMPORT_RES 0 0 0 0 0 0 0 0
0 0 0 0 0 0
4 - 2010-05-07 22:24:25 gpgsm[14692.0] DBG: -> ERR 150995078 BER error
<KSBA>
4 - 2010-05-07 22:24:25 gpgsm[14692.0] DBG: <- BYE
4 - 2010-05-07 22:24:25 gpgsm[14692.0] DBG: -> OK closing connection
[client at fd 4 disconnected]
===========================================================
Would you know what the entries invalid "radix64 character" mean? This error
seems to be repeated with a 32bit Gentoo system of mine too (I initially
suspected that it was only relevant to this amd64 arch).
2nd Bug
Looking into the Gnupg Log Viewer options, I changed the Default log level
from Basic to Guru, to see if I can get some more information about this
error. Well, that proved to be a bad mistake which crippled my log viewer!
Now, I cannot launch the Gnupg Log Viewer. It crashes every time, after it
dumps a load of files like "dbgmd-00001.hash.cert" into ~/.
Also I cannot change the log viewer's default log level anymore! Trying to do
it from within Kleopatra takes, as shown in ~/.gnupg/dirmngr.conf:
===========================================================
###+++--- GPGConf ---+++###
debug-level basic
log-file socket:///home/michael/.gnupg/log-socket
###+++--- GPGConf ---+++### Sat May 8 11:45:20 2010 BST
# GPGConf edited this configuration file.
# It will disable options before this marked block, but it will
# never change anything below these lines.
===========================================================
but as soon as I launch Gnupg Log Viewer it reverts back to Guru. Any idea
what gpgconf reads to reset this damn log level from Basic to Guru?
Remerging a load of apps including dirmngr does not fix it. :-(
This is what the gconf settings for dirmngr show:
===========================================================
$ gpgconf --list-options dirmngr
Monitor:1:0:Options controlling the diagnostic output:0:0::::
verbose:4:0:verbose:0:0::::
quiet:0:0:be somewhat more quiet:0:0::::
no-greeting:0:3::0:0::::
Format:1:0:Options controlling the format of the output:0:0::::
Configuration:1:2:Options controlling the configuration:0:0::::
Debug:1:1:Options useful for debugging:0:0::::
debug-level:18:1:set the debugging level to LEVEL:1:1:LEVEL:"none::"guru
log-file:0:1:write server mode logs to
FILE:32:1:FILE:::"socket%3a///home/michael/.gnupg/log-socket
faked-system-time:0:3::3:3::::
Enforcement:1:0:Options controlling the interactivity and enforcement:0:0::::
force:0:0:force loading of outdated CRLs:0:0::::
HTTP:1:1:Configuration for HTTP servers:0:0::::
disable-http:0:1:inhibit the use of HTTP:0:0::::
ignore-http-dp:0:1:ignore HTTP CRL distribution points:0:0::::
http-proxy:0:1:redirect all HTTP requests to URL:1:1:URL:::
honor-http-proxy:0:1:use system's HTTP proxy setting:0:0::::
LDAP:1:0:Configuration of LDAP servers to use:0:0::::
disable-ldap:0:1:inhibit the use of LDAP:0:0::::
ignore-ldap-dp:0:1:ignore LDAP CRL distribution points:0:0::::
ldap-proxy:0:0:use HOST for LDAP queries:1:1:HOST:::
only-ldap-proxy:0:1:do not use fallback hosts with --ldap-proxy:0:0::::
===========================================================
Any help to solve this mess would be greatly appreciated.
--
Regards,
Mick
Mick
I fixed the second fault. Launching GnuPG Log Manager from Kmail/Tools/GnuPG
Log Manager *without* Kleopatra running allows me to change the default log
level back down to 'basic'. Setting it to 'expert' or 'guru' causes crashes
if Kleopatra is running - so something is definitely amiss. Nevertheless,
it's working again now without crashing, so I'm happy.
Any advice on importing the SSL certificate would be much appreciated.
--
Regards,
Mick