Mon, 28 Aug 2000 19:28:40 -0700 (PDT)
This is a similar situation as before, but I'm once again frustrated
with gpg, so I want to urge again that its user interface be changed.
(I've had similar problems with pgp, so it's not a gpg-specific issue).
Gpg and pgp have lots of well-implemented complicated features but
they both can make it unbelievably difficult to do what should be the
simplest thing in the world: get a public key from your friend, and
use it to send him an encrypted message.
I got a key from my friend and imported it to my public key ring.
Fine. This is a semi-secure machine. Semi-secure means that all
files and network activity are assumed to be monitored by an attacker,
but the attacker won't alter my files even if he reads them. I think
this is the right security model for most shared machines. It means I
have to use reasonable precautions about what kinds of messages I can
compose on it (no problem) and it also means that **I can't have any
private keys on it whatsoever**. Having no private keys means I can't
locally sign my friend's public key, but that's ok--I got it from him
directly and I don't need further authentication for it. An attacker
able to alter my local keyring can also alter my gpg executable, so
I've decided to trust the local keyring.
Again, I want to encrypt a message with my friend's key, this time
after composing the message in emacs. So I pipe the region through
"gpg -ear [friends-name]" and it totally fails because the
stdin/stdout are not connected to a tty in emacs. When I do it in a
shell window, it complains that the key is unsigned and makes me type
"yes" to confirm that I really want to use the key. I don't see *any*
way to turn off that interaction, unless I sign the key, which is
inconvenient and also useless on a semi-secure machine. It means I
can't do the encryption under control of a script, which is really
want I want. --batch, --yes, and --quiet don't do it. --yes doesn't
convince gpg to believe the key (it only answers yes to "most"
questions). --batch and/or --quiet turn off the interaction, but gpg
then just plain refuses to do the encryption because the key is not
signed. And maddeningly, I got idea of trying --completes-needed=0
only to have gpg tell me that completes-needed must be > 0. That
really seems a bug to me. It's ok for the default to be 1, but if I
explicitly specify --completes-needed=0, gpg should believe that I
know what I'm doing and give me what I ask for, instead of imposing
its assumptions on me.
Would it be possible to fix the --completes-needed=0 bug, or
alternatively, maybe add an --override-warnings flag (or even a
--i-know-what-im-doing-so-stop-bothering-me or a
--yes-and-i-really-mean-yes-to-ALL-questions flag), that TOTALLY turns
off the interaction and just makes gpg do what I tell it, without
Archive is at http://lists.gnupg.org - Unsubscribe by sending mail
with a subject of "unsubscribe" to email@example.com