|Summary:||Add Recommends: pinentry-gtk in the .spec file|
|Product:||[Fedora] Fedora||Reporter:||Nuno Dias <nuno.dias>|
|Component:||evolution-data-server||Assignee:||Milan Crha <mcrha>|
|Status:||CLOSED NEXTRELEASE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||24||CC:||bcl, jamielinux, lucilanga, mbarnes, mcrha, nuno.dias, tmraz, tpopela|
|Fixed In Version:||evolution-data-server-3.23.4||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|Last Closed:||2017-01-13 13:31:45 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Nuno Dias 2016-08-02 10:22:02 UTC
Description of problem: When I try to sign a mail with gpg I get this error in the window where I'm writing the mail, after press the sent button Because "gpg: writing to '-' gpg: signing failed: Inappropriate ioctl for device gpg: signing failed: Inappropriate ioctl for device ", you may need to select different mail options. Version-Release number of selected component (if applicable): evolution-3.20.4-1.fc24.x86_64 How reproducible: I can reproduce this every time Steps to Reproduce: 1. Create an email, sign and sent 2. 3. Actual results: Expected results: Additional info:
Comment 1 Milan Crha 2016-08-02 12:01:59 UTC
Thanks for a bug report. Maybe this thread is partly related: http://www.zsh.org/mla/users/2015/msg01175.html together with its follow up message with the user's confirmation. Could you try to open a terminal and run there: $ echo test | gpg2 --sign --armor -u $USER eventually use gpg, instead of gpg2, to check whether the issue can be reproduced also from a terminal, completely out of the evolution? Of course, the terminal can change environment variables mentioned at the above thread, but I believe it does worth a try.
Comment 2 Nuno Dias 2016-08-02 12:55:05 UTC
It works with gpg in terminal, with gpg2 I have the same error in the terminal that I have in evolution. gpg: signing failed: Inappropriate ioctl for device
Comment 3 Milan Crha 2016-08-03 07:13:38 UTC
Thanks for testing it. The gpg2 is the default gpg client these days. You can use: $ gsettings set org.gnome.evolution-data-server camel-gpg-binary "/usr/bin/gpg" to override the binary being used, as a temporary workaround (note that the keys are not shared between gpg2 and gpg1). As you can reproduce this out of the evolution, I'm moving this bug report to the gpg2.
Comment 4 Nuno Dias 2016-08-03 10:01:21 UTC
You say gpg2 and gpg1 are not compatible, so maybe that's the reason this is not working, because my key was generated a long time ago with gpg1. But when trying to generate a new one using gpg2 I have this gpg: agent_genkey failed: No such file or directory Key generation failed: No such file or directory A no key are generated. (In reply to Milan Crha from comment #3) > Thanks for testing it. The gpg2 is the default gpg client these days. You > can use: > > $ gsettings set org.gnome.evolution-data-server camel-gpg-binary > "/usr/bin/gpg" > > to override the binary being used, as a temporary workaround (note that the > keys are not shared between gpg2 and gpg1). > > As you can reproduce this out of the evolution, I'm moving this bug report > to the gpg2.
Comment 5 Tomas Mraz 2016-08-03 10:17:39 UTC
Could be a duplicate of bug 1362572. Isn't there some stale gpg-agent running?
Comment 6 Tomas Mraz 2016-08-03 10:18:35 UTC
Also you should be able to migrate the old key to gpg2 for example via export/import.
Comment 7 Nuno Dias 2016-08-03 10:54:07 UTC
yes, if the gpg-agent is running (and was) I can't generate a new key pair, after kill it I generate a new key pair and the error is the same gpg: signing failed: Inappropriate ioctl for device
Comment 8 Tomas Mraz 2016-08-03 11:24:48 UTC
Unfortunately I cannot reproduce the problem $ echo test | gpg2 --sign --armor -u $USER works fine here.
Comment 9 Tomas Mraz 2016-09-02 12:19:08 UTC
Is this still problem for you with gnupg2-2.1.13? Unfortunately I cannot do much with this without reproducer.
Comment 10 Nuno Dias 2016-09-08 15:00:50 UTC
Right now I don't have problems generate a new key even if the agent is running, but I continue with the problem of can't sign email, so maybe this can be assigned again to evolution.
Comment 12 Nuno Dias 2016-09-08 15:38:04 UTC
Opps sorry, you are right :( still can't sign in the command line gpg: signing failed: Inappropriate ioctl for device -----BEGIN PGP MESSAGE----- Version: GnuPG v2 gpg: signing failed: Inappropriate ioctl for device
Comment 13 Tomas Mraz 2016-09-08 16:22:26 UTC
Do you have GPG_TTY set? What is in your gpg.conf?
Comment 14 Nuno Dias 2016-09-08 17:26:41 UTC
I never changed this file so this is the defaults listing everything not commented grep -v "^#" .gnupg/gpg.conf keyserver hkp://subkeys.pgp.net utf8-strings auto-key-locate local
Comment 15 Nuno Dias 2016-09-08 17:36:26 UTC
I forgot to say that GPG_TTY is empty
Comment 16 Tomas Mraz 2016-09-09 07:56:29 UTC
What's the output of: rpm -qa | grep pinentry
Comment 17 Nuno Dias 2016-09-09 09:14:34 UTC
rpm -qa | grep pinentry pinentry-0.9.7-2.fc24.x86_64
Comment 18 Tomas Mraz 2016-09-09 10:59:43 UTC
So you do not have pinentry-gtk or pinentry-qt installed. Installing it should fix the problem. The question is how did you get into this state, how did you install the system, was it a fresh install or upgrade?
Comment 19 Tomas Mraz 2016-09-09 11:01:05 UTC
Perhaps evolution should have pinentry-gtk or pinentry-qt as Requires or Recommends dependency?
Comment 20 Nuno Dias 2016-09-09 11:17:10 UTC
Thats it, thanks How do I come to not having pinentry-gtk installed? simple, this system was upgraded from version to version since ... I don't know maybe Fedora 10, maybe evolution should have pinentry-gtk as dependency
Comment 21 Milan Crha 2016-09-09 11:50:05 UTC
Right, there is no such dependency and it is correct, from my point of view. While the evolution uses gtk+ and some GNOME-related libraries, it is not stuck with GNOME, it can run also under KDE or any other, where particularly the KDE may prefer the qt version of the pinentry, instead of the gtk version. Another problem is that the code where this is running resides in the evolution-data-server, as a public library, which anyone can use (libcamel). Thus even if I add the pinentry-gtk/-qt to the .spec file of the evolution, it won't help to the other application(s) using the library from the evolution-data-server.
Comment 22 Tomas Mraz 2016-09-09 11:59:23 UTC
Then feel free to close this as wontfix. I do not see how it could be fixed in gpg2 either. Putting the dependency there would be even less appropriate.
Comment 23 Nuno Dias 2016-09-09 12:59:16 UTC
so, then this is simple broken, gpg2 and evolution, because without pinentry-gtk/-qt I can't sign anything, in the command line, because I don't have a popup asking me for the password. gpg2 should work with or without pinentry-gtk and right now doesn't work, right now if gpg-agent is running and pinentry-gtk is not installed doesn't work. So, which component in Fedora(Gnome) is responsible for passing the request of unlock the key from the terminal to the graphical popup? maybe we can assign this to them.
Comment 24 Tomas Mraz 2016-09-09 13:12:18 UTC
Is libcamel used by non-GUI applications at all? If not, then the dependency could be set in evolution-data-server. We could add some virtual provides to both pinentry-gtk and pinentry-qt - pinentry-gui or something that could be required by the evolution-data-server so there is no explicit preference to particular pinentry. gpg2 works fine on command-line without GUI pinentry if you either do not redirect the standard input or set GPG_TTY=$(tty) before running the command with redirection.
Comment 25 Milan Crha 2016-09-12 07:32:07 UTC
(In reply to Nuno Dias from comment #23) > right now if gpg-agent is running and pinentry-gtk is not installed doesn't > work. I think this is the core of the issue. It's the gpg-agent, which requires pinentry-gtk/-qt to work properly in all cases. Evolution is able to ask for a gpg password when the gpg-agent is not active. The problem is that the gpg-agent isn't a package, right? (In reply to Tomas Mraz from comment #24) > Is libcamel used by non-GUI applications at all? I'm not aware of any. I know that Geary (or its fork) will use libcamel "soon", through its GObject introspection code. It's a GUI application too. > If not, then the dependency could be set in evolution-data-server. The libcamel doesn't need any GUI, it doesn't link against gtk+ or anything X/Wayland related. The evolution-data-server has a sublibrary which requires gtk+, but the processes it runs are independent of GUI as well. > We could add some virtual provides to both pinentry-gtk and pinentry-qt - > pinentry-gui or something that could be required by the > evolution-data-server so there is no explicit preference to particular > pinentry. Yeah, the pinentry-gui will be better, thus we do not dictate which version the users should use (gtk or qt). > gpg2 works fine on command-line without GUI pinentry if you either do not > redirect the standard input or set GPG_TTY=$(tty) before running the command > with redirection. Is it meant to "disable" gpg-agent without touching the configuration file? Hmm, even, I think it's not good to disable user preference here. It would lead to another confusion for them. Though the evolution has no tty assigned usually. That said, nothing fits the best here. Adding the soft dependency to the evolution package won't work long term. Then the logical place is the evolution-data-server. It's a core package, thus it may bring more dependencies on the live image or similar places. It needs a discussion with the FESCo or something, I'm afraid (but I'm not sure). The most correct thing, from my point of view, is to make the gpg-agent depend on the pinentry-gui, because in reality it's the gpg-agent which requires it, not the evolution, neither libcamel, nor anything else which runs /usr/bin/gpg2 (see comment #2). But the gpg-agent is part of the gnupg2 package. If the gpg-agent requires some implementation of certain interface, why would it be wrong to mandate it itself, rather than relying on something else to bring it in for it?
Comment 26 Tomas Mraz 2016-09-12 07:42:04 UTC
No, that's a nonsense. gpg-agent does not require GUI pinentry to work properly. It can be used in either loopback mode or with tty pinentry if it knows which tty is to be used to display the PIN entry.
Comment 27 Milan Crha 2016-09-12 09:35:32 UTC
The GUI applications do not have any tty usually. You also said that certain conditions should be met to make it working, where the comment #2 proves that "it can be used...", but it doesn't work out of the box and requires quite some work to be done first. Evolution also _can_ work properly with gpg2's agent without changes in the .spec file. My main point here is to not have a duplicate bug report in the future, for other applications which will need to use gpg2, but will not have installed evolution (I mean to use gpg2 directly, without libcamel or anything, like had been proved in comment #2, where only the command line had been used). The comment #14 also states that it's the default configuration of the gpg2. If there is any setting which can make gpg-agent work always, with or without any pinentry-gui being installed, regardless whether it's run with or without TTY or anything, then the default config of the gpg2 doesn't reflect that. Alternatively, call this a gpg2 bug, because it should, instead of meaning less "gpg: signing failed: Inappropriate ioctl for device", claim "I need password", when it fails to contact the GUI variant of the pinentry. It can claim this error _as a hint_ in the status stream, but nothing else. Also, I just noticed, the libcamel calls gpg with --no-tty argument: https://git.gnome.org/browse/evolution-data-server/tree/camel/camel-gpg-context.c#n585
Comment 28 Tomas Mraz 2016-09-12 09:46:44 UTC
Yes, there is a cosmetic issue or it could be called a bug in gpg2 - that is the error message should be made more clear. Otherwise there is no bug - you have to call gpg2 properly to get successful results. If you want it to prompt via GUI, you have to have something installed that can prompt via GUI. If you do not want to, you have to provide a TTY or call it in a way so it requests the passphrase other way (use --passphrase-fd option). The --no-tty option is unrelated, see the manual page.
Comment 29 Tomas Mraz 2016-09-12 09:57:28 UTC
Reported upstream: https://bugs.gnupg.org/gnupg/issue2680
Comment 30 Milan Crha 2016-09-12 10:07:08 UTC
Thanks, but the report is misleading. First of all the evolution doesn't call gpg that way, what you quoted was only a minimal test command I offered for a quick test. If you check the code link from the end of the comment #27, then you'll see that the evolution calls the gpg much more complicated. > Would it be possible to detect such situation and provide more meaningful > error message? Such as 'Missing tty for displaying passphrase entry.' I would rather like to see a fallback on the gnupg2 to instruct the caller that the password is missing, like it does when gpg-agent is turned off (there was a use-agent option in the past, maybe only in gpg1?). The --passphrase-fd option works only with conjunction with --batch command in gpg2, but the libcamel uses --batch only if no password is needed. There is used the --command-fd to provide passwords, which worked for years. Really, the problem is that gpg2 doesn't claim that it requires password, it simply fails, because gpg-agent failed when it was supposed to ask for the password.
Comment 31 Tomas Mraz 2016-12-21 07:58:02 UTC
Could you please follow up with gnupg2 upstream?
Comment 32 Milan Crha 2016-12-21 09:22:54 UTC
What is their bugzilla, if any, please? As I do not know, I doubt I've an account there and I do not know whether it makes sense to create one just for this single issue, which we discussed in detail here already. (I also ask reporters to file bugs upstream, but I do not force them if they cannot or do not want for whatever reason. In that case I file the bug for them and offer them to CC there.)
Comment 33 Tomas Mraz 2016-12-21 10:17:27 UTC
The bug tracker is mentioned in comment 29 - I've already reported the bug there but you wrote the issue is more complex and I do not fully understand the details here so that's why I am asking you to follow up with upstream directly.
Comment 34 Milan Crha 2016-12-21 16:10:38 UTC
Ouch, I'm sorry, that was a long time and I didn't bother to read the previous comments at all. My fault. I see the bug didn't receive any attraction for the past three months. Could you copy my response from the comment #30 there, all below the cited part, including the two citation lines, and if they would have any additional questions, then just ping me and I'll do my best to follow up? I would even create an account there, bug seeing no interest in the issue by nobody but you and me, it seems like a "waste of time" to create an account there, at lease at the moment.
Comment 36 Tomas Mraz 2016-12-22 11:18:07 UTC
Milan, please read the latest comment from Werner on the upstream bug. Note that we have gnupg2-2.1.17 in rawhide, but we are still at pinentry-0.9.7.
Comment 37 Milan Crha 2016-12-22 15:17:42 UTC
Thanks Tomas. If I try on rawhide with an older gnupg2-2.1.13-2 without any pinentry, then I receive in the Evolution: gpg: no running gpg-agent - starting '/usr/bin/gpg-agent' gpg: waiting for the agent to come up ... (5s) gpg: connection to agent established gpg: writing to '-' gpg: signing failed: No pinentry gpg: signing failed: No pinentry Then I install only the pinentry package, not any of its sub-packages and I receive: gpg: writing to '-' gpg: signing failed: Inappropriate ioctl for device gpg: signing failed: Inappropriate ioctl for device This is expected, it is the older gnupg2. I updated to 2.1.16 with `dnf update gnupg2` (yours today build is not part of the repo yet), and it resulted in: gpg: Fatal: libgcrypt is too old (need 1.7.0, have 1.6.6) Some package version issues there, it seems, not properly handled by dnf. I just run a complete rawhide update, and I'll let you know the next year. I'll have the 2.1.17 by that time too. I'm currently trying to see what it'll claim, if the error truly improved in the 2.1.17 or not (I know you mentioned there's an older version of pinentry). With respect of the request for pinentry-gtk in the evolution package, I did have installed it before I tried the test and it was the seahorse package, which brought it in. Or at least the seahorse package had been removed, when I removed pinentry-gtk. Interestingly nothing required pinentry itself, I could safely remove it too (that was with 2.1.13-2 gnupg2). I'm thinking of requesting pinentry-gtk/-qt somewhere lower in the stack, because the evolution is too high. The thing is that the whole functionality is part of the evolution-data-server's libcamel. There are introspection bindings and vala bindings of it right now, and I've one user whom helped a lot with the introspection, to be able to use the libcamel in his own application, thus without having the evolution installed at all. Another problem I see is that while the Evolution is developed under GNOME umbrella, it's not tight to GNOME at all. There are users running the Evolution under KDE. There makes more sense for them to install pinentry-qt, than pinentry-gtk (I do not know what pinentry picks, when it has both variants, or whether the both can be installed at all). For this I do not think the Evolution should force an install of either of the pinetry-* subpackage. But maybe this is better to deal with in the gnupg-devel list, as suggested in the upstream bug report.
Comment 38 Milan Crha 2017-01-02 16:37:50 UTC
(In reply to Milan Crha from comment #37) > I'm currently trying to see what it'll claim, if the error truly improved in > the 2.1.17 or not (I know you mentioned there's an older version of pinentry). I've installed gnupg2 2.1.17-1.fc26 and pinentry 0.9.7-2.fc24 and with it I get: gpg: no running gpg-agent - starting '/usr/bin/gpg-agent' gpg: waiting for the agent to come up ... (5s) gpg: connection to agent established gpg: writing to '-' gpg: pinentry launched (pid 2174, flavor unknown, version 0.9.7) gpg: signing failed: Inappropriate ioctl for device gpg: signing failed: Inappropriate ioctl for device I suppose it's the reason why you said that the pinentry is too old in the Fedora. I also see that there are 4 different variants of the pinentry subpackages.
Comment 39 Tomas Mraz 2017-01-03 09:11:57 UTC
The pinentry subpackages are installable in parallel and the pinentry script has some logic to choose the best pinentry dialog according to the execution environment.
Comment 40 Milan Crha 2017-01-13 13:31:45 UTC
I'm going to add Recommends: pinentry-gtk into the evolution-data-server.spec for the rawhide, 3.23.4+.