SUMMARY Importing a S/MIME certificate file fails with the error: "gpgsm: Inappropiate IOCTL for device" BUT: manual import with gpgsm from a shell/terminal succeeds Note that kleopatra misses to ask for the installation password of the certificate, unlike gpgsm. I consider this a major error, because "my grandma would not be able to fix it herself". STEPS TO REPRODUCE 1. Import a S/MIME certificate in kleopatra 2. Import the same certificate in a shell with gpgsm 3. OBSERVED RESULT import fails w/o asking for installation password EXPECTED RESULT ask user for installation password, if correct, ask for user's choice of certificates password twice, then import should succeed SOFTWARE/OS VERSIONS Windows: macOS: (available in the Info Center app, or by running `kinfo` in a terminal window) Linux/KDE Plasma: KDE Plasma Version: 6.4.5 KDE Frameworks Version: 6.18.0 Qt Version: 6.9.3 FreeBSD 14.3-RELEASE-p5 ADDITIONAL INFORMATION
Thanks for the report! Unfortunately, none of our test certificates provokes this error. It might be helpful if you could provide some logs. Best use a separate GnuPG folder for this, either by pointing GNUPGHOME to an empty folder or by using a separate user account. To produce logs run GPGME_DEBUG=8:$(pwd)/gpgme-$(date +"%Y-%m-%d-%H%M%S").log kleopatra But wait: This bug report looks like it has the answer/fix: https://dev.gnupg.org/T5885#156154 By the way, don't underestimate grandmas that are using FreeBSD.
(In reply to Ingo Klöcker from comment #1) > Thanks for the report! Unfortunately, none of our test certificates provokes > this error. > > It might be helpful if you could provide some logs. Best use a separate > GnuPG folder for this, either by pointing GNUPGHOME to an empty folder or by > using a separate user account. To produce logs run > GPGME_DEBUG=8:$(pwd)/gpgme-$(date +"%Y-%m-%d-%H%M%S").log kleopatra > > But wait: This bug report looks like it has the answer/fix: > https://dev.gnupg.org/T5885#156154 > > By the way, don't underestimate grandmas that are using FreeBSD. BTW FreeBSDies unually don't use bash(1) but csh(1) instead ;) I deleted the certificate in kleopatra and quit it. Ok, when I do what you asked for, I'm asked in that terminal window to supply the pw and then the import succeeds. But the normal way is to start kleopatra from the GUI, not from a terminal window. IMHO the error is that kleopatra does not start a graphical dialog to ask for the pw and submit that to gpgsm.
Created attachment 186565 [details] debug log from gpgme This is the debug log of gpgme from the successful import, when the pw was given in the terminal window from which kleopatra was started. But this is not the default case, usually it is started from the GUI w/o a terminal attached. Oh nice, here we have the next bug report: some <censored> changed the default type of *.log files to "gaussian log", what a bummer!
For security reasons the password is asked by the dedicated small and easy to audit pinentry application that's called directly by gpg-agent which is the only process that ever sees the private key data. I'm open to suggestions to make the pinentry app work without a TTY on FreeBSD, but that needs to be fixed upstream in GnuPG. I'm closing your report as upstream issue. You are welcome to open a report at dev.gnupg.org (which, unfortunately, is a bit complicated).
(In reply to Ingo Klöcker from comment #4) > [...] > I'm open to suggestions to make the pinentry app work without a TTY on > FreeBSD, but that needs to be fixed upstream in GnuPG. I'm closing your > report as upstream issue. You are welcome to open a report at dev.gnupg.org > (which, unfortunately, is a bit complicated). How does this work on e.g. Linux? If there is an implicit assumption (worst enemy of SW developers) that there must be a TTY, it is a design bug. If pinentry-qt5 or pinentry-qt6 do open a graphical dialog box to ask for the pw, but kleopatra calls the standard (non-GUI) version, it is a bug in kleopatra. If a GUI-aware pinentry should be called by gpgsm but it calls the other pinentry, the bug is in gpgsm. If gpgsm has no chance to know whether there is a TTY or GUI, it is a design bug. The solution could be to add an option to gpgsm instructing it which version of pinentry to call: either TTY (curses) or GUI-aware?
All of this is done by upstream libraries. Frankly, I don't know why the pinentry that seems to be used on your system needs a TTY. The gpgme logs show that /usr/local/bin/pinentry seems to be used. Is this a symlink? Or a script? On my Linux system /usr/bin/pinentry is a shell script that tries to figure out which pinentry program to call, but according to the copyright notices that seems to be a third-party thing. You configure in ~/.gnupg/gpg-agent.conf which pinentry program gpg-agent shall use. See `man gpg-agent`.
(In reply to Ingo Klöcker from comment #6) Yes, /usr/local/bin/pinentry is a symlink to pinentry-ncurses > Or a > script? On my Linux system /usr/bin/pinentry is a shell script that tries to > figure out which pinentry program to call, but according to the copyright > notices that seems to be a third-party thing. > So then it's a design bug IMHO. How can pinentry know if there is a TTY or a GUI? There should be an option (flag) that the calling application can set to tell whether to use the TTY or the GUI version, and which one (Qt or other). IIUC that must be set by kleopatra when calling gpgme-agent (or gpgsm) and that must call the right pinentry. > You configure in ~/.gnupg/gpg-agent.conf which pinentry program gpg-agent > shall use. See `man gpg-agent`. No, this is not the correct solution: maybe from remote over ssh I want to use the TTY version, next day at home I want to use kleopatra and thus the GUI (Qt) version. Note that pinentry-qt works fine (see screenshot).
Created attachment 186595 [details] pinentry-qt
(In reply to Ingo Klöcker from comment #6) gpg-agent already has an option "--pinentry-program" which kleopatra should use (with the file name of the distribution's pinentry-qt), but does not yet do. IMHO that's the bug and the fix should be simple. Rationale: it makes no sense for a KDE/Qt GUI program to call a TTY version of a password-input program, neither to call a program of another GUI toolkit (e.g. Gtk). This way the user's config doesn't need to be changed. When I set this option in ~/.gnupg/gpg-agent.conf: pinentry-program /usr/local/bin/pinentry-qt and kill the running gpg-agent and kleopatra, when I restart kleopatra the import succeeds with the correct pinentry-qt asking for the pw.