[okular] [Bug 483678] Signing with Luxtrust's non-repudiation certificate just hangs

[Alain Knaff]

https://bugs.kde.org/show_bug.cgi?id=483678

--- Comment #8 from Alain Knaff <kde at kde.lka.org.lu> ---
(In reply to Albert Astals Cid from comment #7)
> "Just called Luxtrust about this, they claimed that there was only one
> certificate on the card."
> 
> Well, NSS disagrees if firefox shows 2, not much we can do here really.

Exactly, they _claimed_ ... :-)


In the meantime, I got nss3 patched to get the signature working.
It was a deadlock: the non-working certificate was a "non-repudiation"
certificate which required 2 pin entries (same PIN, but needed to be re-entered
again). While signing, NSS acquires a lock to the card slot, and then calls
PK11_DoPassword to prompt for the "second" password. But unfortunately,
PK11_DoPassword then tries to re-acquire the same lock a second time => which
causes the block.

However, even after fixing this, okular still doesn't work. Now, okular does
pop up a password prompt for password re-entry, but this prompt returns control
immediately to the code, even while the dialog box is still showing (as far as
I can see, it returns an empty password). The password entered by the user is
ignored, and the prompt keeps appearing.

Commenting out the second call to PK11_DoPassword in NSS altogether allows
signature to proceed. Of course, the card (or its pkcs11 module) notices that
the second password was never entered, so now the pkcs11 module pops up its own
password prompt via an X connection that it opened up itself. And that finally
works.

=> I think this points to a threading issue within okular (or poppler?):
SEC_SignData is not really supposed to be called from the thread handling the
GUI. Indeed, this not only freezes the GUI while it does its calculation (or
forever, in the case of a deadlock), but it also becomes iffy if it needs to
call the GUI itself. There is no "clean" way for it to get back to the X client
event loop to wait for password entry, and so has no other choice than return
an empty password as soon as the box is up.
Usually long operations, or operations that could potentially block, are
supposed to be run from another thread than the thread handling the GUI.

-- 
You are receiving this mail because:
You are the assignee for the bug.