Werner Koch wk at isil.d.shuttle.de
Mon Sep 21 09:34:44 CEST 1998

Brian Warner <warner at lothar.com> writes:

>  1. Encrypting to a key that is not fully trusted in --batch mode causes that
>     key to be dropped from the recipient list. --yes should cause gpg to use
>     the key anyway. (without --batch the user is warned and asked if the key

What about --always-trust - can't you use this ?

>     is hard to figure out which key has the problem). It would be handy if
>     untrusted keys in --batch mode without --yes were listed on stderr, with a

I have added the keyid to all messages.

>  2. "--passphrase-fd 0" is unimplemented. My workaround is to use a perl

No. the checks/*test do use it.  You must send the passphrase as a
single line before the data.  I have changed the way it is handled:
Now the passphrase is read direct after programm startup and not when
it is needed.  I guess the problem was that it only worked for stdin
if there was no arguiment on the commandline.  

>  3. giving a hex keyid for -r or -u that is the wrong type of subkey should
>     just use the right subkey for the operation. In particular the primary
>     keyid should be useable for everything, since the primary keyid is the
>     easiest value to get by parsing the output of --list-keys.

I was wondering whether I should really do this (see TODO) but you now
convinced me.

>  4. --import from a file that contains multiple key block messages seems to
>     quit after the first one. All blocks should be imported.

It's already on my TODO list.

>  5. There should be a way to drive --edit-key from a system() call. The Gnome
>     PGP graphical front end <http://maxcom.ml.org/gpgp/>, which uses GPG
>     despite the name, would probably benefit from this.

I don't think so:  The problem is that there is no secure way to pass
the passphrase to gpg (we can't do this with passphrase-fd because one
might have different passphrases).  The solution I already implemented
uses shared memory IPC to drive gpg.  See tools/shmtest.c for an

Thanks for your suggestions.


More information about the Gnupg-devel mailing list