Re: [Mutt] #2873: Support for gpg groups
#2873: Support for gpg groups
Comment (by John Washington):
{{{
This isn't focused on just mailing lists, there are other cases where
this would be appropriate. For example, a recovery key for the
enterprise. It also seems logical to use features available in GPG,
as if it is available someone (like me) will find a use for it.
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:>