Re: MML, message-send-hook and automatically GnuPG-signing messages.

[Florian Weimer <fw@s.netic.de>]

Jonas Steverud <d4jonas@dtek.chalmers.se> writes:

> > Yes, that's the idea.  You probably want to add extra information to the
> > `<#encrypted>' tag, for example the recpients' key ID.
> 
> Could you please explain what you ment with that? I have spend almost
> half the day hacking on this so if you have some idea on how to make
> my life more easy I am most happy to listen. 

By private mail, I'll send you all my code and some discussion which
has taken place on this list over a year ago.

> The probelm with the code
> you presented was that mc/gnupg did not find any information regarding
> whom to send to. 

Well, it was a crude hack to see which interfaces are necessary.

> I have made a hack for that (an additional argument to
> rfc2015-generate-enclosed-parts-and-funcall) but you maybe have come
> accross a better solution.

No, that's the correct solution, I think.  Perhaps you should pass the
intitial value of the `cont' parameter, IIRC it contains all the
necessary information.

> (A "feature" I see now:
> To: a@b.c, e@b.c, q@p.c
>  #multipart type=encrypted recpients="a@b.c">
>  Secret text to a.
>  #/multipart>

Yes, that's the idea.  Ideally, the user wouldn't write MML on his own,
but invoke a command which displays a suitable subset of the public key
ring, lets the user mark the keys he wants to use, and Emacs generates
the appropriate MML directives.

> > > There where possibilities to intercept my passphrase but the work
> > > and luck that was needed was too great. You needed to be root to
> > > begin with (which is a bit hard on a well administred system).
> > 
> > In fact, this is not necessary, and that's the problem. :(
> 
> Can you develop that? Let us presume a system where we can trust the
> sysadmin to be competent.

I'm sorry, the fix isn't ready yet, so I won't elaborate it in public.