enhancements

[Brian Warner]

wk at isil.d.shuttle.de (Werner Koch) writes:
> 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 ?

Oops, yes, that works perfectly. I should read through the options structure
some more.. there are all kinds of handy tricks lurking in there. Does
--gen-prime still do anything? :-).

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

Thanks.

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

In 0.4.0, this only worked for me when signing or clearsigning a
message. Decrypting doesn't work: I get a message that the passphrase is
wrong. If I modify passphrase.c to print the passphrase after it is entered, I
see that it is always null.

That makes sense if gpg was reading it from fd 0 but not reading it until it
was known to be necessary. I suspect that signing worked because we know in
advance that we need the passphrase, before the plaintext is read. For
decryption the plaintext gets read first, then we discover that a passphrase
is needed, but by that point it's too late. I also notice that if the key I'm
signing with isn't protected with a passphrase, the passphrase I tried to give
actually ends up in the message body. Always reading the passphrase if fd==0
right at the start should take care of that too.

(incidentally, in my test I was surprised to see that my key wasn't protected
with a passphrase. I was sure I had used --edit-key and "passwd" to set one
after importing it from my 5.0 keyring. Is it possible that the secondary
[encryption] key could have a passphrase but the primary [signature] key might
not? If so, which does --edit-key "passwd" affect?)

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

Ahh, that makes sense. Cool.

thanks,
 -Brian