Recipient inconstistence

Matthew Byng-Maddick gnupg at lists.colondot.net
Tue Aug 14 20:26:01 CEST 2001


On Tue, Aug 14, 2001 at 12:42:08PM -0400, David Shaw wrote:
> On Tue, Aug 14, 2001 at 12:45:34PM +0200, Werner Koch wrote:
> > > your reasoning on Alice's part is broken. If Alice does that, then she's
> > > not acting a good part in the protocol.
> > It is more a practical problem.  She replies and obviously can't
> > encrypt for Bob but the MUA may have set Bob into the CC.  It takes
> > some time to pass all messages then again to Bob.  I have made that
> > experience several times and therefore I think it might be better for
> > GnuPG to fail if any recipient is not valid so that it is obvious for
> > the MUA not to send the message.

I didn't mean to contest this, I just felt it was, on the other hand your
original reasoning for this that was the problem.

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

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

MBM

-- 
Matthew Byng-Maddick         <mbm at colondot.net>           http://colondot.net/




More information about the Gnupg-devel mailing list