Thank you for taking the time to report this issue to us.  This is an issue which is best addressed by the upstream developers.

It appears your issue is different enough from what has been reported that I would open a new report

Please file a report at bugs.kde.org , and when done add the upstream report info to this report.

We will continue to track the issue in the centralized upstream bug tracker, and will review any bug fixes that become available for consideration in future updates.

Thank you for the bug report.

This bug has been triaged

Steven M. Parrish
KDE & Packagekit Triager 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

I don't believe this is a problem with kleopatra. It's a problem with the underlying program, gpgsm -> call-protect-tool.

When I try to import a .p12 file using gpgsm, I get the following:

[bob 2009]$ gpgsm --import enckey.p12
gpgsm: gpg-protect-tool: 1224 bytes of 3DES encrypted text
gpgsm: gpg-protect-tool: decryption failed; trying charset `ISO-8859-1'
gpgsm: gpg-protect-tool: decryption failed; trying charset `ISO-8859-15'
gpgsm: gpg-protect-tool: decryption failed; trying charset `ISO-8859-2'
gpgsm: gpg-protect-tool: decryption failed; trying charset `ISO-8859-3'
gpgsm: gpg-protect-tool: decryption failed; trying charset `ISO-8859-4'
gpgsm: gpg-protect-tool: decryption failed; trying charset `ISO-8859-5'
gpgsm: gpg-protect-tool: decryption failed; trying charset `ISO-8859-6'
gpgsm: gpg-protect-tool: decryption failed; trying charset `ISO-8859-7'
gpgsm: gpg-protect-tool: decryption failed; trying charset `ISO-8859-8'
gpgsm: gpg-protect-tool: decryption failed; trying charset `ISO-8859-9'
gpgsm: gpg-protect-tool: decryption failed; trying charset `KOI8-R'
gpgsm: gpg-protect-tool: decryption failed; trying charset `IBM437'
gpgsm: gpg-protect-tool: decryption failed; trying charset `IBM850'
gpgsm: gpg-protect-tool: decryption failed; trying charset `EUC-JP'
gpgsm: gpg-protect-tool: decryption failed; trying charset `BIG5'
gpgsm: gpg-protect-tool: data error at "decrypted-text", offset 3714184591
gpgsm: gpg-protect-tool: error at "bag-sequence", offset 49
gpgsm: gpg-protect-tool: error parsing or decrypting the PKCS-12 file
gpgsm: error running `/usr/libexec/gpg-pro
tect-tool': exit status 2
gpgsm: total number processed: 0

I tried other keys that I have successfully imported before with the same results as above. This obviously has worked in the past; this is the first import I've tried using FC12.


The gpgsm binary is contained in gnupg2-2.0.13-1.fc12.x86_64

Let's reassign this to gnupg2 then (and cancel the needinfo for upstreaming for now).

Does it ask for a passphrase or not at all?

What 'echo $GPG_AGENT_INFO' prints?

If you do 'unset GPG_AGENT_INFO ; gpgsm --import <pkcs12file>', does it work?

Do you have installed pinentry and/or pinentry-gtk?

Does not ask for pass phrase. 

echoing GPG_AGENT_INFO yields  /tmp/gpg-V337bH/S.gpg-agent:8112:1

After doing an unset, it WORKS! Import is successful.

You probably already know that kde in the file 
/etc/kde/env/gpg-agent-startup.sh
is setting the GPG_AGENT_INFO to use the file in /tmp   Is a /tmp a problem? Is it worthwhile to explore what happens if I edit that file to point GPG_AGENT_INFO to ~/tmp?

Thanks much,
Bob

Is a gpg-agent running on your system?

If you run gpg-agent what does it print?

Yes, the agent is running.
A ps -ef yields /usr/bin/gpg-agent -s --daemon --write-env-file

After unsetting GPG_AGENT_INFO, I get

gpg-agent                                                                                                 
gpg-agent[18415]: can't connect to `/home/bob/.gnupg/S.gpg-agent': No such file or directory
gpg-agent: no gpg-agent running in this session. 

I'll have to kill the agent and log back in to see what happens before I did the unset.

Logged out, the back in. Now when I run gpg-agent, I get

gpg-agent: gpg-agent running and available

Of course, now the p12 import won't work unless I go and 'unset' GPG_AGENT_INFO.

kleopatra still does not work.

Even with the gpgsm import working, I'm getting the decryption error that started this thread when I try to import a p12 file using kleopatra.

the same for me ...

gpgsm --import fails

gpg-agent is running:
$ gpg-agent
gpg-agent: gpg-agent running and available
$ echo $GPG_AGENT_INFO
/tmp/gpg-2oporx/S.gpg-agent:1559:1

unsetting GPG_AGENT_INFO leads to gpgsm --import working, bringing up pinentry-qt

(In reply to comment #9)
> kleopatra still does not work.
> 
> Even with the gpgsm import working, I'm getting the decryption error that
> started this thread when I try to import a p12 file using kleopatra.  

I suppose unsetting GPG_AGENT_INFO was valid just for the shell you've tried the commands, not globally ...

So that seems like there is something broken with the gpg-agent running from the session startup. It looks like it cannot successfully spawn the pinentry or the pinentry fails - for example because it cannot open a window on the X display or whatever.
You could strace the gpg-agent process to find out where it fails.
I do not use KDE so I don't know how gpg-agent is started in the session and I cannot reproduce the problem on Gnome.

A possibility I've seen in cases of pinentry failing is:
~/.gnupg/gpg-agent.conf
containing a
pinentry-program
key that points to something wrong/bogus.

These days, that key is almost never needed.

I think this is not the case as the pinentry-qt is working fine in case the gpg-agent is executed directly from the gpg-sm - in the unset GPG_AGENT_INFO case. If there was a bogus config entry in gpg-agent.conf it would not probably work in this case either.

Created attachment 381979 [details]
strace -s 1000 -p 1559 &> gpg-agent.strace

$ gpgsm --import ~/usercert.p12
gpgsm: gpgsm: GPG_TTY has not been set - using maybe bogus default
gpgsm: gpg-protect-tool: 640 bytes of 3DES encrypted text
gpgsm: gpg-protect-tool: decryption failed; trying charset `ISO-8859-1'
gpgsm: gpg-protect-tool: decryption failed; trying charset `ISO-8859-15'
gpgsm: gpg-protect-tool: decryption failed; trying charset `ISO-8859-2'
gpgsm: gpg-protect-tool: decryption failed; trying charset `ISO-8859-3'
gpgsm: gpg-protect-tool: decryption failed; trying charset `ISO-8859-4'
gpgsm: gpg-protect-tool: decryption failed; trying charset `ISO-8859-5'
gpgsm: gpg-protect-tool: decryption failed; trying charset `ISO-8859-6'
gpgsm: gpg-protect-tool: decryption failed; trying charset `ISO-8859-7'
gpgsm: gpg-protect-tool: decryption failed; trying charset `ISO-8859-8'
gpgsm: gpg-protect-tool: decryption failed; trying charset `ISO-8859-9'
gpgsm: gpg-protect-tool: decryption failed; trying charset `KOI8-R'
gpgsm: gpg-protect-tool: decryption failed; trying charset `IBM437'
gpgsm: gpg-protect-tool: decryption failed; trying charset `IBM850'
gpgsm: gpg-protect-tool: decryption failed; trying charset `EUC-JP'
gpgsm: gpg-protect-tool: decryption failed; trying charset `BIG5'
gpgsm: gpg-protect-tool: data error at "decrypted-text", offset 1509237059
gpgsm: gpg-protect-tool: error at "bag-sequence", offset 15
gpgsm: gpg-protect-tool: error parsing or decrypting the PKCS-12 file
gpgsm: error running `/usr/libexec/gpg-protect-tool': exit status 2
gpgsm: total number processed: 0

Created attachment 381980 [details]
strace -s 1000 -f -p 1559 &> gpg-agent.strace

Hmm pinentry-qt trying to read from terminal? Dunno why.

One more try, temporarily replace /usr/bin/pinentry-qt with ln -s /bin/env /usr/bin/pinentry-qt . (Save a backup :)

And do the same strace as above.

Created attachment 381990 [details]
/usr/bin/pinentry-qt => /bin/env

$ gpgsm --import ~/usercert.p12
gpgsm: gpgsm: GPG_TTY has not been set - using maybe bogus default
gpgsm: gpg-protect-tool: error while asking for the passphrase: No pinentry
gpgsm: error running `/usr/libexec/gpg-protect-tool': exit status 2
gpgsm: total number processed: 0

see /etc/kde/env/gpg-agent-startup.sh , it does set GPG_TTY var.

Hrm... except not always,

  if [ -f "${GPG_AGENT_INFO_FILE}" ]; then
    export GPG_AGENT_INFO=$(cat "${GPG_AGENT_INFO_FILE}")
    export GPG_TTY=$(tty)
  else
    eval "$(${GPG_AGENT} -s --daemon ${GPG_OPTIONS})"
    echo ${GPG_AGENT_INFO} > "${HOME}/.gpg-agent-info"
  fi

(ie, the latter case, of starting a new gpg-agent).

But is the GPG_TTY real problem here? The main problem as I see it is that the gpg-agent although it receives the X display with the 'OPTION display=:0' command, it does not pass it to pinentry neither through command line option, nor through environment, nor through an OPTION command.

Now I am really getting a grip of it.

This is regression caused by this upstream SVN commit:
http://cvs.gnupg.org/cgi-bin/viewcvs.cgi?rev=5064&root=GnuPG&view=rev

which triggers a bug in gpg-protect-tool. It does not properly initialize the gpg agent options like a DISPLAY and others.

The workaround which should probably help is to put keep-display option to .gnupg/gpg-agent.conf.

I can confirm that the keep-display workaround works for me.

Unfortunately the upstream still did not respond on the issue.

updating the version, the same seems to happen in F13
(gnupg2-smime-2.0.14-4.fc13.x86_64)

any news from upstream?

No, unfortunately no news at all.

(In reply to comment #4)
> Does it ask for a passphrase or not at all?
> 
> What 'echo $GPG_AGENT_INFO' prints?
> 
> If you do 'unset GPG_AGENT_INFO ; gpgsm --import <pkcs12file>', does it work?

for me works, pop-up pinentry-qt ( I use kde) 

thanks,

In reply to Sergio, Yes, it works if GPG_AGENT_INFO is unset.

Can someone please tell me purpose of GPG_AGENT_INFO? Before I unset it, the value is something like
GPG_AGENT_INFO=/tmp/gpg-AqNiv4/S.gpg-agent:2165:1

Thanks

if you do
ps   
echo $GPG_AGENT_INFO 
you see that you are in TTY->pts/n
changing to other shell and if you do again:
ps   
echo $GPG_AGENT_INFO
you see that you are in other TTY but have same GPG_AGENT_INFO , so if set a keychain with: 
keychain ~/.ssh/id_dsa -q
yours keychain will work in other TTY because have ( or read ) same  GPG_AGENT_INFO

updating version - it happens also using Fedora 14

however, there is some difference: the "Decryption failed" dialogue now does not appear, it fails silently instead (or maybe I was just too impatient ... it told me something about background actions running when closing Kleopatra)

unsetting GPG_AGENT_INFO works; not just for gpgsm but it even allows Kleopatra to import the certificate, if started from the terminal where GPG_AGENT_INFO is not set

Actually there are some changes in gnupg-2.0.16 that should help fix the problem. Can you please repeat the strace as of comment 18?

Created attachment 468628 [details]
strace -s 1000 -f -p 2030 &> gpg-agent.strace

here you are ...

can you use strace -v - I'm interested in the environment variables passed to the pinentry-qt4 which is being executed.

Oops my comment 32 is a misinformation - it seems to be fixed only in the svn trunk and not on the 2.0 branch.

I'll prepare a package with the fix from upstream so you can test it.

(In reply to comment #35)
> I'll prepare a package with the fix from upstream so you can test it.

Tom, hasn't the patch already been included?

I tried to re-test, and after some initial problems(*), both kleopatra and gpgsm import seems to work fine

- Kleopatra complains about not being able to contact gpg-agent, but once I dismiss the selftest dialogue, it starts "gpgsm --server" and "gpg-agent --server" in the background

if I run gpg-agent manually, I have to explicitly export GPG_AGENT_INFO ... and if the agent is dead and GPG_AGENT_INFO exists, the same as above happens, i.e. kleopatra complains and then "gpg-agent --server" is started

(*) on first kleopatra run, the import partially failed - saying 1 key not imported, and I couldn't see any certificates listed, no matter clicking to refresh the list and waiting for ages ... when trying to quit kleopatra, it said there's some background task running, so I left it running for a while (+- 5 minutes), but it did nothing, then I closed kleopatra despite the warning - but this condition did not reappear on any of the subsequent tries

Perhaps the changes in gnupg2-2.0.17 could positively affect the problem.

I wonder if this could be closed then ... anyone still experiencing any problems?

I encountered this issue today on Fedora 15 (x86_64) with KDE 4.7 (kdelibs-4.7.0-1.fc15.x86_64 from kde-redhat unstable repository).

Adding the "keep-display" option to gpg-agent.conf solved the problem. (pinentry-qt4 is now displayed and passwords get accepted.)

I have gnupg2-2.0.17-1.fc15.x86_64 installed.

(In reply to comment #36)
> I tried to re-test, and after some initial problems

well, now it seems I have isolated the problem and it seems to happen 100% reproducibly

after system startup, trying to use gpgsm fails, it hangs forever (similar symptomes as I've described with Kleopatra running "something" in background)

the gpg-agent is running:

kvolny    1765     1  0 08:56 ?        00:00:00 /usr/bin/gpg-agent -s --daemon --write-env-file

but it seems stuck - trying to kill it doesn't do anything, I have to use "kill -9", then gpgsm operation continues normally

oh no , I got same problem again with F16 and kde 4.7.4

Created attachment 576677 [details]
Patch fixing gpg-protect-tool session_env handling

Ok, so given that the keep-display workaround is 1) ugly and 2) breaks much more than it fixes, here's a proper fix.

The problem was gpg-protect-tool (PKCS#12 helper called by gpgsm to decrypt the source bundle) was not initialising session_env properly and that prevented send_pinentry_environment() from doing its job (passing relevant environment vars like DISPLAY to agent and in turn, pinentry), so pinentry-qt had no clue which X session to use and either bailed out or possibly popped the curses fallback interface somewhere.
(Easy Reader version: Not a Kleopatra bug, but a gnupg2 one.)

Applying this tiny patch on top of gnupg2-2.0.18-2.fc16.x86_64 fixes both gpgsm --import and kleopatra.

Tomáš Trnka, please report the patch also upstream to https://bugs.g10code.com/ or if you cannot/do not want to do it, I can do it for you.

(In reply to comment #44)
> Tomáš Trnka, please report the patch also upstream to https://bugs.g10code.com/
> or if you cannot/do not want to do it, I can do it for you.

Done: https://bugs.g10code.com/gnupg/issue1402