On Wed, 2005-04-06 at 20:37 +1200, Matt Brown wrote: > On Wed, 2005-04-06 at 16:27 +0800, Not Zed wrote: > <snip> > > Right. Well, I think, considering that this code already changes > > camel-gpg-context, and that is probably the easiest/cleanest way to do > > this, I don't see a problem in actually implementing this more in the > > core code than just doing it as a plugin; aside from demonstrating it > > could be done in a plugin. > > > > Since: > > - the additions to em-inline-filter should be small. > > - the changes to camel-gpg-context are small. > > - the only other thing needed is a application/x-inline-pgp 'handler', > > which should be really quite small (maybe it will need to distinguish > > between signed/encrypted somehow, but header parameters or a separate > > type could do that). > > I agree with everything previous. However, I think we only need to use > an application/x-inline-pgp type for inline signed messages. For > encrypted messages it is easy to build a multipart/encrypted and pass > that to the decrypt function. not so sure about this actually, since the encrypted content in a multipart/encrypted is an entire mime part encrypted (e.g. it has content headers and such) and so it'd be significant changes to the gpg-context code to make it output a mime part from a non-mime-part stream. it may require api changes to camel-cipher-context to do it the way you're planning on it. not sure how best to solve this. -- Jeffrey Stedfast Evolution Hacker - Novell, Inc. fejj ximian com - www.novell.com
Attachment:
smime.p7s
Description: S/MIME cryptographic signature