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
> 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