[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: Problems sending encrypted messages
From:       Rob Walker <rob () myinternetplace ! net>
Date:       2002-01-31 19:03:31
[Download RAW message or body]

On Thursday 31 January 2002 12:19, Ingo Klöcker wrote:

> It's too late for this because we are in a message freeze. ;-)

but not too late for 3.0.1 :-)

> But the real reason is that I didn't want this because:

> 1.) We would have to treat GnuPG and PGP differently because the usage 
> of untrusted keys is only possible with gpg (and the completely 
> outdated PGP 5 AFAIK). But all classes (except the program dependant 
> classes derived from Kpgp::Base) should be free of any hacks which only 
> apply to one of the supported programs.

Here I go displaying my lack of knowledge again....  How are gpg's "untrusted 
keys" different from the pgp keys which Geheimnis displays as "possibly valid 
keys"

I think that the user should be allowed to sign and encrypt whatever they want 
to to whomever they want to.  However, it may very well be that Kpgp::Base 
should be what supports this, not something extra we put into kmail.

> 2.) man gpg:
> 	--always-trust
>                  Skip  key  validation  and assume that used keys
>                  are always fully trusted.  You  won't  use  this
>                  unless  you have installed some external valida­
>                  tion scheme.
>     Do we (or you) have an external validation scheme? No!

We have a user saying "I want to do it."  Doesn't that provide enough 
validation?  Not having this feature doesn't stop a user from sending their 
email, since they will either just start signing locally to get it done (I 
suppose it isn't the best thing, but would it be better to generate a key 
especially for local signing, so that other people know not to trust it?) or 
they will do it outside of kmail.  The former, I don't like (forcing users to 
do non-standard things to use our app) and the latter seems like it will push 
people away from kmail in the long run.

> 3.) This feature (not allowing encrytion with untrusted keys) will 
> probably accelerate the growth of the web of trust because now KMail 
> users are forced to sign keys if they want to use them.  Hopefully they 
> won't just sign them locally (or even worse, globally without checking 
> the key owner's identity). I know that this is wishful thinking. :-(

:-)  I think you rightly judge people.  They will do the first thing that they 
can do which will allow them to get the most work done with the least effort. 
If this means signing keys (and they don't know what locally vs. globally 
means, they will do whatever just happens by default) over-zealously, then it 
will happen.

rob
_______________________________________________
kmail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail
[prev in list] [next in list] [prev in thread] [next in thread]