<<< Date Index >>>     <<< Thread Index >>>

Re: [Mutt] #2873: Support for gpg groups



#2873: Support for gpg groups

Comment (by John Washington):

 {{{
 The other problem is that this breaks the trust model of gpg, as the
 message isn't encrypted end to end.  I am in a situation where the reason
 we are doing this is because we do not trust the listserv totally, hence
 wish to protect the messages sent there.

 On Nov 23 at  8:36 am, Mutt handed me the following bytes:
 > #2873: Support for gpg groups
 >
 > Comment (by Derek Martin):
 >
 >  {{{
 >  On Tue, Nov 20, 2007 at 05:21:11PM +0100, Gregor Zattler wrote:
 >  > I second this or some other means to enable encryption to several
 >  > keys which have no corresponding recipent in the email headers.
 >  > If crypt-hook would allow for multiple keys or would not test if
 >  > there actually is a (valid) pub key corresponding to the provided
 >  > string this also would solve the problem.
 >  >
 >  > Using a shared key for a mailing list is not the best option
 >  > because one would have to create and communicate a new key
 >  > whenever a member of the list leaves the list (and possibly also
 >  > when someone joins the list).  For lists with only a few members
 >  > who know exactly who is on the list this feature would make
 >  > things much easier.
 >  >
 >  While I don't really oppose this, it seems to me that the far saner
 >  way to deal with this is for the mailing list software to allow the
 >  subscribing users to upload their public key, and to make the mailing
 >  list software decrypt and re-encrypt the message with all of the
 >  subscriber's keys.  I don't think that's a problem Mutt should have to
 >  fix (and the sender shouldn't need to have everyone's keys).
 >
 >  IOW, the sender encrypts to one key: the mailing list's public key.
 >  The list management software should do the rest.
 >  }}}
 >
 > --
 > Ticket URL: <http://dev.mutt.org/trac/ticket/2873#comment:>
 >
 >
 }}}

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/2873#comment:>