Re: [Evolution-hackers] Preliminary patches to add inline PGP support

[Matt Brown <matt mattb net nz>]

On Wed, 2005-04-06 at 12:32 -0400, Jeffrey Stedfast wrote:

> > 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.

Good point, I had forgotten about this when I wrote the previous email.
It also brings up the point of how the hell I'm meant to know what type
of data exists within the inline encrypted block... 

> 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.

OK, so how about this. 

We use the existing inline-scanner to recognise inline pgp blocks in
text/plain messages and break them out into application/x-inline-pgp
mime parts. The mime part will have an option/parameter (not sure of the
correct terminology?) format={signed,encrypted}. 

We add a formatting handler for application/x-inline-pgp which passes
the message to verify or decrypt (as appropriate), then calls
em_format_secure to display the decrypted/verified part. 

I will make further modifications to camel-gpg-context to support
decryption of application/x-inline-pgp parts in a similar way to how
they are currently handled for verification. 

The details of determining what type of content have been decrypted can
be handled in the formatter, once I work out what the best thing to do
in this case is. 

Regards

-- 
Matt Brown
matt mattb net nz
Mob +64 275 611 544 www.mattb.net.nz