Mailing List Archive: GnuPG: devel

1.4.4 unable to reopen standard input error

Index | Next | Previous | View Threaded

kyle at memoryhole

Jul 20, 2006, 5:09 PM

Post #1 of 3 (1144 views)
Permalink

1.4.4 unable to reopen standard input error

Hello,

I recently upgraded gnupg from 1.4.2 to 1.4.4, and suddenly I am
running into a nasty problem.

I use mutt on MacOS X (10.4.7) for all my email needs, and one of the
things I can do (well, used to be able to do) is decode and reply to
“traditional” pgp-encoded email (a-la what is generated by pine users
who send encrypted email). After upgrading gnupg, I can no longer
reply to emails that have been encrypted in the “traditional”
(translation: inline ascii) manner. I can decrypt them just fine, but
whatever re-decryption mutt does when replying merely produces:

gpg: fatal: unable to reopen standard input, output, or error

The command that mutt runs to decode such email is this:

gpg --status-fd=2 --no-verbose --quiet --batch --output - %f

Where "%f" is replaced by the name of the file to decrypt (mutt saves
the encrypted message to a file and then runs gpg on it).

I understand there was a patch that went into gnupg 1.4.4
(http://lists.gnupg.org/pipermail/gnupg-devel/2006-May/022915.html
patch-stdout.reopen.patch) that may have something to do with this. Is
there anything I can do to fix this? I'm tempted to track down that
patch and reverse it on my 1.4.4 source, to see if that doesn't fix
it.

Interestingly, other people on the mutt mailing lists who also use
gnupg 1.4.4 (but do so on Linux) do not have the problem.

~Kyle
--
He who dares not offend cannot be honest.
-- Thomas Paine

wk at gnupg

Jul 21, 2006, 4:05 AM

Post #2 of 3 (1071 views)
Permalink

Re: 1.4.4 unable to reopen standard input error [In reply to]

On Fri, 21 Jul 2006 02:09, Kyle Wheeler said:

> (http://lists.gnupg.org/pipermail/gnupg-devel/2006-May/022915.html
> patch-stdout.reopen.patch) that may have something to do with this. Is
> there anything I can do to fix this? I'm tempted to track down that
> patch and reverse it on my 1.4.4 source, to see if that doesn't fix it.

It is important that stdin, stdout and stderr are open and thus
connected to some file descriptor. If for example stderr is closed
and gpg opens another file (like the trustdb or a keyring) and later
prints a message to stderr it will end up in that file - oops. Thus
it is always required to make sure that the standard file descriptors
are connected; i.e. to dup them to /dev/null right before the exec
call.

To figure out your problem you should run mutt under "strace -f" or
whatever system call trace utility you have on your system. grep for
the exec of gpg and then check what happended to descriptors 0,1,2
right before that.

As an alternative you might want to add

set crypt_use_gpgme

into your .muttrc and use the modern gpg interface.

Shalom-Salam,

Werner

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel[at]gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

dshaw at jabberwocky

Jul 21, 2006, 5:56 AM

Post #3 of 3 (1067 views)
Permalink

Re: 1.4.4 unable to reopen standard input error [In reply to]

On Thu, Jul 20, 2006 at 08:09:41PM -0400, Kyle Wheeler wrote:
> Hello,
>
> I recently upgraded gnupg from 1.4.2 to 1.4.4, and suddenly I am
> running into a nasty problem.
>
> I use mutt on MacOS X (10.4.7) for all my email needs, and one of the
> things I can do (well, used to be able to do) is decode and reply to
> “traditional” pgp-encoded email (a-la what is generated by pine users
> who send encrypted email). After upgrading gnupg, I can no longer
> reply to emails that have been encrypted in the “traditional”
> (translation: inline ascii) manner. I can decrypt them just fine, but
> whatever re-decryption mutt does when replying merely produces:
>
> gpg: fatal: unable to reopen standard input, output, or error
>
> The command that mutt runs to decode such email is this:
>
> gpg --status-fd=2 --no-verbose --quiet --batch --output - %f

Are you sure that is the command? I see no way for the passphrase to
be passed there.

David

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel[at]gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com