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.
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.
Hmm, that should have read "by having RPM do that before exec()ing gpg".
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.
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
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.
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.)