Re: [Evolution-hackers] S/MIME support

[Ettore Perazzoli <ettore ximian com>]

Aside from the changes in Camel, a big part of this is also integrating
the necessary bits in the addressbook and doing all the certificate
managing that is needed.

On Thu, 2003-07-03 at 12:28, Jeffrey Stedfast wrote:
> On Thu, 2003-07-03 at 11:41, Not Zed wrote:
> > Hi Bernard,
> > 
> > > I'm interested in adding support for S/MIME to Evolution and have seen a
> > > number of requests/mentions of this feature.
> > > 
> > > Is anyone currently working on it?  If not has anyone tried and given up (war
> > > stories welcome!)?  Does anyone have any suggestions on how I can get started
> > > on such a task?  Where could I find the relevant documentation on how to get
> > > started with hacking evolution?
> > 
> > We're planning it for 1.6 i think.  Jeff will be working on it, he'll
> > probably reply when he wakes up :)
> > 
> > He's already done some (nontrivial) work on it in the past, but i'm not
> > sure whether it managed to do anything or was just experimentation.
> > 
> > There is no documentation, apart from the source.  There is a basic
> > object and class structure for high-level
> > encrypt/decrypt/signing/verification, and an implementation for gpg, but
> > thats about it.  We want to keep similar api's and a common abstraction
> > at least for these high-level operations for different backends (for
> > plugins?).
> > 
> > Source to look at (in an evolution tarball or on cvs.gnome.org in the
> > evolution dir) ...
> > 
> > Stuff in camel/*
> >   camel-cipher-context.[ch]
> > 	abstract high-level class for use by the mime classes
> >   camel-gpg-context.[ch]
> > 	implementation for gpg/pgp
> >   camel-multipart-signed.[ch]
> > 	handle reading/writing multipart/signed type (rfc3156)
> > 	ignore most of my whiney comments :)
> 
> (abstractly defined in rfc1847 - applies to both S/MIME and PGP/MIME)
> 
> >   camel-multipart-encrypted.[ch]
> > 	handle reading/writing multipart/encrypted type
> 
> unfortunately not helpful for S/MIME, since it does encryption a
> different way :-(
> 
> > 
> > this stuff is there but doesn't work/isn't used
> >   camel-cms-context.[ch]
> > 	similar to cipher-context for s/mime
> 
> right, altho ideally what should happen is that cms-context and
> cipher-context get merged.
> 
> A few things:
> 
> CamelCipherValidity will have to become some sort of chain if it is
> going to be used by the S/MIME code (since, as far as I understand, the
> Mozilla nss verification code uses a chain that might not be easy to
> flatten. or, even if it can be flattened - should it?)
> 
> >   camel-smime-context.[ch]
> > 	similar to gpg context
> 
> the basics are there, nothing tested tho. I don't even completely recall
> where exactly I left off.
> 
> >   camel-pkcs7-context.[ch]
> > 	pkcs7 for cipher-context implementation?
> 
> this is garbage. When I originally started implementing S/MIME, the APIs
> were different in nss.
> 
> > 
> > There's also some utility stuff, but its mostly for identifying/etc. 
> > The frontend code just consists of calling *multipart* methods with the
> > right context.
> > 
> > The plan (i think a requirement?) is to use Mozilla's libNSS to
> > implement it.
> 
> right.