Bug 483678 - Signing with Luxtrust's non-repudiation certificate just hangs
Summary: Signing with Luxtrust's non-repudiation certificate just hangs
Status: REPORTED
Alias: None
Product: okular
Classification: Applications
Component: PDF backend (show other bugs)
Version: 22.12.2
Platform: Debian stable Linux
: NOR normal
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-03-15 15:07 UTC by Alain Knaff
Modified: 2024-03-19 07:51 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alain Knaff 2024-03-15 15:07:34 UTC
SUMMARY
***
NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols.
See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports
***


STEPS TO REPRODUCE
1. Connect Smart card reader with Luxtrust card to computer
2. View PDF form using okular
3. Click "show signatures panel"
4. In signatures panel, right click and chose sign
5. When asked, enter smart card's PIN
6. Chose LuxTrusV5: User Cert Sig (i.e. the certificate for "Non Repudiation" rather than "Digital Signature, Encrypt Keys"
7. Click Ok

OBSERVED RESULT

okular just freezes :-(
okular's UI no longer refreshes, and okular needs to be killed with Control-C
No diagnostic on stdout/stderr (except unrelated "evaluate() threw an exception" due to "This PDF file requires a newer version of Adobe Acrobat Reader DC." popup at document load)

EXPECTED RESULT

It should sign the document and allow me to save it. Or if not possible / allowed, plainly state why in a popup.

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: 
(available in About System) menu item not present
KDE Plasma Version: 142
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8

ADDITIONAL INFORMATION

- Signing using the second certificate on the same smartcard works just fine
- Signing using a PKCS12 certificate (file-based, rather than card) just works fine too
Comment 1 Alain Knaff 2024-03-15 15:26:21 UTC
Just called Luxtrust about this, they claimed that there was only one certificate on the card.

=> so the problem seems to be that okular is listing certificates which should not be used. Remark about going into a hang, rather than popping up a clear message still stands.
Comment 2 Albert Astals Cid 2024-03-16 10:57:22 UTC
Are you using the nss or the gpg backend?

Don't confirm your own bugs.
Comment 3 Alain Knaff 2024-03-16 12:47:05 UTC
NSS
Comment 4 Alain Knaff 2024-03-16 23:27:51 UTC
I now wanted to try whether it works better with gpg, but I couldn't find how to switch to gpg.

In Settings->ConfigureBackends->PDF, it seems to assume NSS, and there is no switch to use GPG

Or is this in an entirely different place in settings? If so, where?
Comment 5 Albert Astals Cid 2024-03-18 17:44:34 UTC
(In reply to Alain Knaff from comment #4)
> I now wanted to try whether it works better with gpg, but I couldn't find
> how to switch to gpg.
> 
> In Settings->ConfigureBackends->PDF, it seems to assume NSS, and there is no
> switch to use GPG
> 
> Or is this in an entirely different place in settings? If so, where?

It's there, i see you're probably using a too old version of okular/poppler for it to show up.

How many certificates do you get shown in Firefox->Own certificates preferences page?
Comment 6 Alain Knaff 2024-03-18 21:48:02 UTC
(In reply to Albert Astals Cid from comment #5)
> (In reply to Alain Knaff from comment #4)
> > I now wanted to try whether it works better with gpg, but I couldn't find
> > how to switch to gpg.
> > 
> > In Settings->ConfigureBackends->PDF, it seems to assume NSS, and there is no
> > switch to use GPG
> > 
> > Or is this in an entirely different place in settings? If so, where?
> 
> It's there, i see you're probably using a too old version of okular/poppler
> for it to show up.

I retried with okular 23.08.1 from Debian testing, and with a poppler that I compiled myself (24.03.0), and GPG still didn't show up :-(

> 
> How many certificates do you get shown in Firefox->Own certificates
> preferences page?

I see 3 certificates: the 2 from the smartcard, and an old expired software CA cert that I happened to have lying around
Comment 7 Albert Astals Cid 2024-03-18 22:07:28 UTC
"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.
Comment 8 Alain Knaff 2024-03-18 23:01:00 UTC
(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.
Comment 9 Sune Vuorela 2024-03-19 07:51:25 UTC
(In reply to Alain Knaff from comment #6)

> I retried with okular 23.08.1 from Debian testing, and with a poppler that I
> compiled myself (24.03.0), and GPG still didn't show up :-(

Unfortunately you need a newer gpg than what is currently available in debian (We needed some fixes for handling of padding in signatures)

You could find the gnupg appimage which should contaain a okular and a gnupg that just works together.  It can be started with adding `-c okular` to the app image call.

Alternatively, if you can sign a <anything> using either gpgsm on the command line, or the graphical KDE Application `Kleopatra`, with your luxtrust key then it is likely that the okular-with-gnupg-smime setup would also work.