There's more than one bugs that I need to report so please bear with me as I 
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