warner at lothar.com
Tue Sep 22 02:08:12 CEST 1998
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.
> > 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
Ahh, that makes sense. Cool.
More information about the Gnupg-devel