Bug 197602

Summary: gnupg update to 1.4.4 disturbs rpm
Product: [Fedora] Fedora Reporter: Ralf Corsepius <rc040203>
Component: rpmAssignee: Paul Nasrat <nobody+pnasrat>
Status: CLOSED UPSTREAM QA Contact: Mike McLean <mikem>
Severity: medium Docs Contact:
Priority: medium    
Version: 5CC: nalin, pasteur
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-07-07 03:34:58 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ralf Corsepius 2006-07-04 14:32:08 UTC 
Description of problem:
A recent gnupg update (presumably to gnupg-1.4.4-2) desturbs rpm:

# rpm  --resign *.rpm
Enter pass phrase:
Pass phrase is good.
avr-rtems4.7-gcc-4.0.3-0.20060704.0.fc5.i386.rpm:
gpg: WARNING: standard input reopened
gpg: WARNING: standard input reopened

Left to the eye of the beholder to judge if this gpg behavior is useful.
Comment 1 Nalin Dahyabhai 2006-07-06 21:09:14 UTC 
This happens when gnupg is started as a subprocess with nothing connected to its
stdin descriptor (0).  Strictly speaking it's not an error, but if it needs to
be suppressed it probably needs to be done by having RPM do that exec()ing gpg.
 Reassigning to 'rpm' to get more input.
Comment 2 Nalin Dahyabhai 2006-07-06 21:11:25 UTC 
Hmm, that should have read "by having RPM do that before exec()ing gpg".
Comment 3 Paul Nasrat 2006-07-06 21:41:14 UTC 
We're using:

-14: __gpg      /usr/bin/gpg
-14: __gpg_check_password_cmd   %{__gpg}
        gpg --batch --no-verbose --passphrase-fd 3 -u "%{_gpg_name}" -so -
-14: __gpg_sign_cmd     %{__gpg}
        gpg --batch --no-verbose --no-armor --passphrase-fd 3 --no-secmem-warning
        -u "%{_gpg_name}" -sbo %{__signature_filename} %{__plaintext_filename}

--no-tty doesn't seem to help here.
Comment 4 Paul Nasrat 2006-07-06 21:44:10 UTC 
This looks to be the commit:

http://lists.gnupg.org/pipermail/gnupg-commits/2006-May/006485.html

I would have thought --batch and --no-tty should have been taken into account
here from the man page
Comment 5 Jeff Johnson 2006-07-07 03:34:58 UTC 
Hehe, rpmdb had stderr splatted on the wrong file descriptor years and years before gpg.

This (atm untested) patch prolly solves the problem:
Index: signature.c
===============================================================
====
RCS file: /cvs/devel/rpm/lib/signature.c,v
retrieving revision 2.155.2.19
diff -u -b -B -w -p -r2.155.2.19 signature.c
--- signature.c 31 Mar 2006 17:38:16 -0000      2.155.2.19
+++ signature.c 7 Jul 2006 03:40:44 -0000
@@ -429,7 +429,6 @@ static int makePGPSignature(const char *
        const char *path;
        pgpVersion pgpVer;
 
-       (void) close(STDIN_FILENO);
        (void) dup2(inpipe[0], 3);
        (void) close(inpipe[1]);
 
@@ -577,7 +576,6 @@ static int makeGPGSignature(const char *
     if (!(pid = fork())) {
        const char *gpg_path = rpmExpand("%{?_gpg_path}", NULL);
 
-       (void) close(STDIN_FILENO);
        (void) dup2(inpipe[0], 3);
        (void) close(inpipe[1]);
 
I'll verify and checkin a fix before rpm-4.4.7. Messing around with macros and gpg args is silly imho.
Comment 6 Nalin Dahyabhai 2006-07-07 14:27:56 UTC 
Jeff, does rpm start leaking a descriptor to gnupg with that patch?  Would it be
better to open /dev/null on STDIN_FILENO?  (The latter seems to be what gnupg
would prefer, anyway.)