Bug 548528

Summary: kleopatra fails to import certificate - Decryption failed
Product: [Fedora] Fedora Reporter: Karel Volný <kvolny>
Component: gnupg2Assignee: Rex Dieter <rdieter>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 16CC: amarecek, andreas.petzold, axel.thimm, devurandom, grewater, jreznik, kevin, ltinkl, mathstuf, nalin, rdieter, robert.b.miller, sergio, smparrish, than, tmraz, tomastrnka, tuju
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: gnupg2-2.0.19-1.fc18 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 622539 (view as bug list) Environment:
Last Closed: 2012-05-02 10:26:39 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 622539    
Attachments:
Description Flags
strace -s 1000 -p 1559 &> gpg-agent.strace
none
strace -s 1000 -f -p 1559 &> gpg-agent.strace
none
/usr/bin/pinentry-qt => /bin/env
none
strace -s 1000 -f -p 2030 &> gpg-agent.strace
none
Patch fixing gpg-protect-tool session_env handling none

Description Karel Volný 2009-12-17 12:47:08 EST
Description of problem:
When trying to import certificate protected by password, instead of invoking pinentry, kleopatra fails saying "Decryption failed".

Version-Release number of selected component (if applicable):
kdepim-4.3.4-1.fc12.x86_64

How reproducible:
always

Steps to Reproduce:
1. create storage dir
mkdir -p ~/.pki/nssdb
2. create a new database
certutil -N -d ~/.pki/nssdb
3. create self signed certification authority
certutil -S -k rsa -n cacert -s "CN=cacert" -v 12 -t "C,C,C" -x -d ~/.pki/nssdb
4. create user certificate signed by the authority
certutil -S -k rsa -c cacert -n usercert -s "CN=usercert" -v 12 -t "u,u,u" -d ~/.pki/nssdb
5. create the PKCS12 certificate file protected by a password
pk12util -o ~/usercert.p12 -n usercert -d ~/.pki/nssdb
6. try to import the certificate in kleopatra
kleopatra -i ~/usercert.p12
  
Actual results:
a dialogue saying "Decryption failed" appears, nothing imported

Expected results:
pinentry shows up to get the password, certificate is imported after entering valid password

Additional info:
this may (or may not) be related to the upstream bug https://bugs.kde.org/show_bug.cgi?id=217334
Comment 1 Steven M. Parrish 2009-12-22 10:11:42 EST
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
Comment 2 Bob Miller 2010-01-05 08:53:38 EST
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
Comment 3 Kevin Kofler 2010-01-05 09:01:37 EST
Let's reassign this to gnupg2 then (and cancel the needinfo for upstreaming for now).
Comment 4 Tomas Mraz 2010-01-05 09:33:09 EST
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?
Comment 5 Bob Miller 2010-01-05 10:04:28 EST
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
Comment 6 Tomas Mraz 2010-01-05 10:14:53 EST
Is a gpg-agent running on your system?

If you run gpg-agent what does it print?
Comment 7 Bob Miller 2010-01-05 10:32:46 EST
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.
Comment 8 Bob Miller 2010-01-05 10:36:28 EST
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.
Comment 9 Bob Miller 2010-01-05 11:12:41 EST
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.
Comment 10 Karel Volný 2010-01-05 11:19:57 EST
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
Comment 11 Karel Volný 2010-01-05 11:21:31 EST
(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 ...
Comment 12 Tomas Mraz 2010-01-05 11:31:19 EST
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.
Comment 13 Rex Dieter 2010-01-05 11:51:31 EST
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.
Comment 14 Tomas Mraz 2010-01-05 15:52:42 EST
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.
Comment 15 Karel Volný 2010-01-06 08:12:06 EST
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
Comment 16 Karel Volný 2010-01-06 08:15:40 EST
Created attachment 381980 [details]
strace -s 1000 -f -p 1559 &> gpg-agent.strace
Comment 17 Tomas Mraz 2010-01-06 08:31:28 EST
Hmm pinentry-qt trying to read from terminal? Dunno why.
Comment 18 Tomas Mraz 2010-01-06 08:41:14 EST
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.
Comment 19 Karel Volný 2010-01-06 08:51:03 EST
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
Comment 20 Rex Dieter 2010-01-06 08:55:58 EST
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).
Comment 21 Tomas Mraz 2010-01-06 11:38:04 EST
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.
Comment 22 Tomas Mraz 2010-01-06 15:55:04 EST
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.
Comment 23 Andreas Petzold 2010-01-15 09:33:07 EST
I can confirm that the keep-display workaround works for me.
Comment 24 Tomas Mraz 2010-01-18 03:24:13 EST
Unfortunately the upstream still did not respond on the issue.
Comment 26 Karel Volný 2010-08-09 12:29:40 EDT
updating the version, the same seems to happen in F13
(gnupg2-smime-2.0.14-4.fc13.x86_64)

any news from upstream?
Comment 27 Tomas Mraz 2010-08-09 12:41:41 EDT
No, unfortunately no news at all.
Comment 28 Sergio Monteiro Basto 2010-12-10 21:22:33 EST
(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,
Comment 29 Bob Miller 2010-12-11 09:11:46 EST
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
Comment 30 Sergio Monteiro Basto 2010-12-11 12:50:39 EST
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
Comment 31 Karel Volný 2010-12-13 06:19:00 EST
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
Comment 32 Tomas Mraz 2010-12-14 10:14:22 EST
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?
Comment 33 Karel Volný 2010-12-14 10:36:08 EST
Created attachment 468628 [details]
strace -s 1000 -f -p 2030 &> gpg-agent.strace

here you are ...
Comment 34 Tomas Mraz 2010-12-14 11:57:24 EST
can you use strace -v - I'm interested in the environment variables passed to the pinentry-qt4 which is being executed.
Comment 35 Tomas Mraz 2010-12-14 12:10:32 EST
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.
Comment 36 Karel Volný 2011-06-29 07:45:10 EDT
(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
Comment 37 Tomas Mraz 2011-06-29 07:58:21 EDT
Perhaps the changes in gnupg2-2.0.17 could positively affect the problem.
Comment 38 Karel Volný 2011-06-30 04:39:32 EDT
I wonder if this could be closed then ... anyone still experiencing any problems?
Comment 39 GWater 2011-08-14 19:04:54 EDT
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.)
Comment 40 GWater 2011-08-14 19:06:06 EDT
I have gnupg2-2.0.17-1.fc15.x86_64 installed.
Comment 41 Karel Volný 2011-08-16 10:13:26 EDT
(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
Comment 42 Sergio Monteiro Basto 2011-12-24 10:54:54 EST
oh no , I got same problem again with F16 and kde 4.7.4
Comment 43 Tomáš Trnka 2012-04-11 01:57:04 EDT
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.
Comment 44 Tomas Mraz 2012-04-11 02:32:13 EDT
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.
Comment 45 Tomáš Trnka 2012-04-11 16:36:26 EDT
(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