Mailing List Archive: enhancements

enhancements

Sep 20, 1998, 7:55 PM

Post #1 of 4 (608 views)

-----BEGIN PGP SIGNED MESSAGE-----

I've gotten the mailcrypt+gpg code basically working, and have sent it to the
mailcrypt maintainer for inclusion in the next release. In working on it,
I came across a number of enhancements to GPG that would make --batch control
much easier. (listed by decreasing significance)

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
should be used anyway, although the name of the key is not printed so it
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
message about what the problem was, causing an error return
status. Something like:

gpg: foo: no valid trust path

2. "--passphrase-fd 0" is unimplemented. My workaround is to use a perl
script that looks for this in the argument list and creates a pipe to
itself to send the passphrase to a different fd, then exec's the real
GPG. It works, but it would be great to not have to install a wrapper.
The basic problem is that emacs-lisp doesn't provide a way to write to
any file descriptor other than a subprocess' stdin.

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.

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

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.

thanks,
-Brian
warner@lothar.com
-----BEGIN PGP SIGNATURE-----
Version: GNUPG v0.4.0 (GNU/Linux)
Comment: Get GNUPG from ftp://ftp.guug.de/pub/gcrypt/

iEYEARECAAYFAjYFv/YACgkQkDmgv9E5zEzijACeKOsoKP2C5DC/+Mq7R315RrQChDgAoKYs
5/WatfEacqN8Hq89iQCoppwE
=L9Gy
-----END PGP SIGNATURE-----

Re: enhancements [ In reply to ]

wk at isil

Sep 20, 1998, 11:34 PM

Post #2 of 4 (605 views)

Permalink

Brian Warner <warner@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
example.

Thanks for your suggestions.

Werner

Re: enhancements [ In reply to ]

warner at lothar

Sep 22, 1998, 1:08 AM

Post #3 of 4 (602 views)

Permalink

wk@isil.d.shuttle.de (Werner Koch) writes:
> Brian Warner <warner@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

Re: enhancements [ In reply to ]

wk at isil

Sep 22, 1998, 2:10 AM

Post #4 of 4 (600 views)

Permalink

Brian Warner <warner@lothar.com> writes:

> 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? :-).

Only if you uncomment MAINTANER_OPTIONS somewhere at the top of
g10/g10.c.

> (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?)

That is a bug. The same passphrase is used for all keys. I add a
warning to --edit-key when a key is not protected.

Werner