Bug 197602 - gnupg update to 1.4.4 disturbs rpm
gnupg update to 1.4.4 disturbs rpm
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2006-07-04 10:32 EDT by Ralf Corsepius
Modified: 2009-06-29 05:03 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-07-06 23:34:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ralf Corsepius 2006-07-04 10:32:08 EDT
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.
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 17:09:14 EDT
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 17:11:25 EDT
Hmm, that should have read "by having RPM do that before exec()ing gpg".
Comment 3 Paul Nasrat 2006-07-06 17:41:14 EDT
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 17:44:10 EDT
This looks to be the commit:


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-06 23:34:58 EDT
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
diff -u -b -B -w -p -r2.155.2.19 signature.c
--- signature.c 31 Mar 2006 17:38:16 -0000
+++ 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 10:27:56 EDT
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.)

Note You need to log in before you can comment on or make changes to this bug.