Hide Forgot
Description of problem: I'm attempting to set up a Sigul Server and Bridge, both on F23 hosts but cannot get it to work. Version-Release number of selected component (if applicable): sigul-0.100-6.fc23.noarch How reproducible: always Actual results: The Sigul Server logs: 2016-04-22 16:03:12,027 DEBUG: Started processing a request 2016-04-22 16:03:12,031 INFO: Request: 'key' = 'my-key', 'op' = 'sign-rpm', 'user' = 'jflorian' 2016-04-22 16:03:12,153 INFO: Connection from E=jflorian,CN=jflorian,OU=Sigul Clients,O=doubledog.org,L=Mason,ST=Michigan,C=US 2016-04-22 16:03:12,364 ERROR: Error signing ('my-package', None, '23', '4.fc23', 'noarch', 'f1a60655b3ef0f111b04f49c654092a046851a5fd3a0ec38279fdd45f4d4ed3b0acc8a9e4c1e8eb68c3ab2eabb3e81c34883b16c62cb2d0d69a137a2563e6d28'): End Of File (EOF). Exception style platform., output /tmp/tmpYCxTAG: gpg: signing failed: Line passed to IPC too long gpg: signing failed: Line passed to IPC too long error: gpg exec failed (2) 2016-04-22 16:03:12,364 INFO: Request error: Unknown error 2016-04-22 16:03:12,470 DEBUG: Request handling finished 2016-04-22 16:03:12,527 DEBUG: Waiting for a request Expected results: A usable setup. Additional info: I was able to get things working in a prior deployment using F21 but wanted this new deployment based on something that wasn't EoL. My last attempt was with EPEL7 but that resulted in #1308754. I'm pretty sure my setup is OK; many sigul commands work: e.g., list-keys, sign-text. But I cannot get sign-rpm to do any better than shown above. If F23 isn't reasonably feasible I'd very much appreciate a pointer to what would be best.
Thanks for your report. Just by looking at the error message, I’m afraid I have no idea what this is about. The relevant limit is > #define ASSUAN_LINELENGTH 1002 /* 1000 + [CR,]LF */ and this may be some communication between sigul/gpgme,gnupg(2?),pintentry. I’d suggest a (strace -ff -s 1024) on the sigul server, and trying to find this (both the component reporting the error, and the input causing it) from there.
(re: sigul on F23: Even this may not be sufficient to make sigul work. Apart from bug #1322971, running (rpm --addsign) manually suggests that the prompts from rpm have changed and sigul will not be able to provide a passphrase. So this a “yes, I see the failure too” but I’m afraid I won’t have time to make this work on F23 any time soon if it is non-trivial. FWIW, a sigul-0.102 setup with F22 client, and CentOS 6.7 bridge and server, and a custom gnupg1, does work for me.) OK, reproduced. I can’t see how that error happens. The root cause is in pinentry-curses, it seems to be communicating with its client just fine, and then suddenly a reported error with no obvious reason: > read(3, "SETPROMPT Passphrase:", 1002) = 21 > read(3, "\n", 981) = 1 > write(4, "OK", 2) = 2 > write(4, "\n", 1) = 1 > read(3, "GETPIN", 1002) = 6 > read(3, "\n", 996) = 1 > rt_sigaction(SIGALRM, {0x55e8d68ab8f0, [], SA_RESTORER, 0x7f3472b4eb20}, NULL, 8) = 0 > alarm(60) = 0 > open("/dev/pts/1", O_RDONLY) = 5 > open("/dev/pts/1", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 6 > open("/usr/lib64/gconv/gconv-modules.cache", O_RDONLY) = 7 > fstat(7, {st_mode=S_IFREG|0644, st_size=26254, ...}) = 0 > mmap(NULL, 26254, PROT_READ, MAP_SHARED, 7, 0) = 0x7f347396e000 > close(7) = 0 > close(5) = 0 > close(6) = 0 > stat("/var/lib/sigul/gnupg/S.gpg-agent", {st_mode=S_IFSOCK|0755, st_size=0, ...}) = 0 > utime("/var/lib/sigul/gnupg/S.gpg-agent", NULL) = 0 > write(4, "ERR 83886343 Line passed to IPC too long <Pinentry>", 51) = 51 > write(4, "\n", 1) = 1 reassigning, could you take a look please?
Miloslav, thank you for all that feedback, especially confirmation that I hadn't done something stupidly wrong and for the bridge/server platform details for a combo known to be working. This helps me significantly.
Just a random thought: Could you try hacking gpg2 as the default gpg binary and retry? I.e. doing something like # mv /usr/bin/gpg /usr/bin/gpg1 # ln -s /usr/bin/gpg2 /usr/bin/gpg The gpg2 binary should not use pinentry at all while being UI-compatible with gpg1, maybe it could serve as a workaround until this is debugged and fixed.
(In reply to Boris Ranto from comment #4) > The gpg2 binary should not use pinentry at all while being UI-compatible > with gpg1 If you mean that gpg2 will ask the user on /dev/tty, that would not help: sigul needs to supply its computed passwords to the gpg process, (actually, in this case, a gpg subprocess of RPM) without any user interaction.
I was wondering more if it would make the issue disappear. The pinentry(-curses) can't work properly unless it gets an interactive terminal (you can bypass that with tools like 'script' which allow you to simulate one) -- in fact it will just plain quit if it detects it is not on a tty . The simpler versions of pinentry-like tools (like the one in gpg2) can often-times get away with non-interactive terminals. and things like 'echo "password" | gpg' might work there. AFAICR, gpg had no way to tell it to not query for passwords from stdin and 'script' had to be used to simulate tty to provide password when piping.
(In reply to Boris Ranto from comment #4) > Just a random thought: Could you try hacking gpg2 as the default gpg binary > and retry? I.e. doing something like > > # mv /usr/bin/gpg /usr/bin/gpg1 > # ln -s /usr/bin/gpg2 /usr/bin/gpg > > The gpg2 binary should not use pinentry at all while being UI-compatible > with gpg1, maybe it could serve as a workaround until this is debugged and > fixed. Tried this but it makes server fail to verify passphrase - WARNING: Request authentication failed: passphrase does not match
(In reply to Boris Ranto from comment #6) > I was wondering more if it would make the issue disappear. The > pinentry(-curses) can't work properly unless it gets an interactive terminal > (you can bypass that with tools like 'script' which allow you to simulate > one) -- in fact it will just plain quit if it detects it is not on a tty . > AFAICR, gpg had no way to tell it to not query for passwords from stdin and > 'script' had to be used to simulate tty to provide password when piping. IIRC (this is from memory), gpg1 can be run in batch mode, where the passphrase is supplied via a file descriptor, and gpgme supports this mode, and that's how most of sigul works. This didn’t work in gpg2 for a long time, which is why sigul insists on gpg1. Reportedly there is now a pinentry loopback mode, I didn’t look into it and sigul doesn’t implement it. Still, this failure comes from https://git.fedorahosted.org/cgit/sigul.git/tree/src/server.py#n815 , i.e. when the gpg automation is performed by rpm, not even by sigul. Most importantly, see the strace above; why is pinentry suddenly reporting a line too long for no obvious reason?
Trying on Centos 6.7 (bridge is still F23) I still can't get sigul to sign RPMs - seems to be stuck in gpg/pinentry (sigul-0.97-1.el6.noarch, gnupg2-2.0.14-8.el6.x86_64) Custom gnupg1 is required?
Nevermind, just found https://people.redhat.com/mitr/rpmsigner/rhel6/ and it signed my rpm.
It probably errors out because it is not on a tty. It is a generic gpg error and (a brief google search suggests that) it happens when an utility from gpg family does not get a tty. What do you mean by pinentry loopback mode? The pinentry-tty? That is not enabled in fedora, yet. I can enable it if you want me to, though. While there is the batch mode it does not guarantee that gpg binary won't try to read from stdin (see the man page). If the key requires a password, it will query for it from stdin (which should be a tty if it uses pinentry-curses). The rpm signing does require a tty because of all of this. You can use e.g. expect to simulate the tty for rpm signing: expect << EOF spawn rpm --resign $_rpm expect "Enter pass phrase:" send -- "password\r" expect eof EOF
(In reply to Boris Ranto from comment #11) > It probably errors out because it is not on a tty. It is a generic gpg error > and (a brief google search suggests that) it happens when an utility from > gpg family does not get a tty. If “Line passed to IPC too long” is indeed used to report a “generic gpg error” or even “an utility did not get a TTY”, that’s a very confusing behavior worth fixing IMHO. Not that it would make sigul work, but at least there would be one less inexplicable roadblock. > What do you mean by pinentry loopback mode? Honestly I haven’t looked into the gpgv2 pinentry automation facilities. There weren’t any for a long time (#842074), now they supposedly are some but I didn’t look into it. > While there is the batch mode it does not guarantee that gpg binary won't > try to read from stdin (see the man page). If the key requires a password, > it will query for it from stdin (which should be a tty if it uses > pinentry-curses). sigul is creating all keys it uses, so their behavior is pretty consistent. In practice, in gpg1 this all worked fine. > The rpm signing does require a tty because of all of this. You can use e.g. > expect to simulate the tty for rpm signing: The sigul code I linked above does use an expect-like library already. It may well need adjusting, sure, but we are not that far yet. First we need to figure out why the “Line passed to IPC too long” error message happens and how to fix whatever is broken and causing it.
(In reply to Miloslav Trmač from comment #12) > ... > If “Line passed to IPC too long” is indeed used to report a “generic gpg > error” or even “an utility did not get a TTY”, that’s a very confusing > behavior worth fixing IMHO. Not that it would make sigul work, but at least > there would be one less inexplicable roadblock. > It is not completely generic but it is used in more than one place and it is defined in libgpg-error library. It is also one of the reasons why I think this happens because you are not giving pinentry (rpm --sign) a proper tty. I suspect that the problem is that the simple ttys do not understand the terminal control sequences and interpret them as an input/output. All of ncurses is built on top of control sequences so that is why you can't really fix this with pinentry-curses. You can usually use expect to simulate a better tty or you might look into using pinentry-tty which should be much more suitable for those simple ttys. It is not currently enabled in fedora but I can look into enabling it if you want to use it. btw: You can override the 'to-be-used' pinentry binary when you set the PINENTRY_BINARY environment variable.
(In reply to Boris Ranto from comment #13) > (In reply to Miloslav Trmač from comment #12) > > ... > > If “Line passed to IPC too long” is indeed used to report a “generic gpg > > error” or even “an utility did not get a TTY”, that’s a very confusing > > behavior worth fixing IMHO. Not that it would make sigul work, but at least > > there would be one less inexplicable roadblock. > > > > It is not completely generic but it is used in more than one place and it is > defined in libgpg-error library. Fine. Could you, or someone, fix, that please? > I suspect that the problem is that the simple ttys do not understand the > terminal control sequences and interpret them as an input/output. All of > ncurses is built on top of control sequences so that is why you can't really > fix this with pinentry-curses. That’s not what the strace above shows, AFAICS: it opens a new PTY, which succeeds, it checks for an existence of an agent socket, which succeeds again, and then it just fails with that garbage error message. No communication actually occurs on that PTY. Knowing the real reason instead of guessing which of many “generic” failures this one represents would help us move forward.
I was playing with this a bit and it does not seem to be related to the tty. I previously managed to overlook that you already use expect in sigul... However, the rpmsign was apparently reworked in recent fedoras and it does not ask me for a password at all nowadays (I use password-less keys, I was previously required to input a password even for those). Also, the output of the command changed so the expect calls probably won't work. We should involve rpm-sign maintainer -> re-assigning (there does not seem to be any rpmsign component in the bz -> targetting rpm directly)
(In reply to Boris Ranto from comment #15) > However, the rpmsign was apparently reworked in recent fedoras and it does > not ask me for a password at all nowadays (I use password-less keys, I was > previously required to input a password even for those). Yeah; sigul uses password-protected keys, though. > Also, the output of the command changed so the expect calls probably won't > work. Yes, as already suggested in comment#2. > We should involve rpm-sign maintainer -> re-assigning (there does not > seem to be any rpmsign component in the bz -> targetting rpm directly) I can’t see why the rpm-sign maintainers would be better suited for diagnosing the confusing pinentry error message, but I’ll let them decide.
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
The problem occurs when neither TERM or DISPLAY are set in the environment, I can reproduce with eg [pmatilai@sopuli rpm]$ cp ~/Downloads/xfce4-terminal-0.8.2-2.fc25.x86_64.rpm /tmp/; env -i HOME=/home/pmatilai DISPLAY=:0 ./rpmsign --addsign /tmp/xfce4-terminal-0.8.2-2.fc25.x86_64.rpm /tmp/xfce4-terminal-0.8.2-2.fc25.x86_64.rpm: gpg: signing failed: Operation cancelled gpg: signing failed: Operation cancelled error: gpg exec failed (2) [pmatilai@sopuli rpm]$ This is apparently a bug in pinentry, upstream report here: https://bugs.gnupg.org/gnupg/issue2452
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
FWIW this appears to have gotten fixed in the meanwhile, in Fedora 28 and pinentry-1.1.0-2.fc28.x86_64 I can no longer reproduce the issue with the recipe from comment #19.
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.