Recipient inconstistence

David Shaw dshaw at
Wed Aug 15 06:51:01 CEST 2001

On Tue, Aug 14, 2001 at 06:24:41PM +0100, Matthew Byng-Maddick wrote:
> On Tue, Aug 14, 2001 at 12:42:08PM -0400, David Shaw wrote:

> > I think you are correct.  The user asked GnuPG to do something
> > (encrypt to Bob and Alice).  GnuPG couldn't do this, as Bob's key is
> > missing.  Therefore, GnuPG should fail.
> By default yes. But GnuPG is a good, and configurable piece of software,
> and therefore, if I tell it that I know what I'm doing, then it should
> do what I tell it.

Yes, absolutely.

> > Security software that tries to be too helpful concerns me - if there
> > is a problem, I want to know about it :)
> I don't think it's being "helpful" in this case, it's doing what eg. rm
> does, by default, to assume you know what you're doing, and that you have
> in fact made all the appropriate checks beforehand.
> > I'm not against an option that allows GnuPG to continue and encrypt
> > only to Alice, but I would argue it should be disabled by default.
> OK. This sounds sensible. I wasn't actually disagreeing on this, (or if I
> was, it wasn't meant that way), I was more disagreeing with Werner's
> reasoning for this - that Alice didn't know who it was encrypted to, and
> that Alice trusts me to tell her the truth about what I'm sending.

I think we agree here. :) I tend to look at software commands (and
again, especially security software) as being as atomic as possible.
Either it succeeds completely, or it fails completely.  As you point
out, "rm" doesn't do that.  A "--force" command would be great.


   David Shaw  |  dshaw at  |  WWW
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

More information about the Gnupg-devel mailing list