Re: [Evolution-hackers] S/MIME support

[Not Zed <notzed ximian com>]

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 :)
  camel-multipart-encrypted.[ch]
	handle reading/writing multipart/encrypted type

this stuff is there but doesn't work/isn't used
  camel-cms-context.[ch]
	similar to cipher-context for s/mime
  camel-smime-context.[ch]
	similar to gpg context
  camel-pkcs7-context.[ch]
	pkcs7 for cipher-context implementation?

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.

And just some other things of note (i dont know how much of this you
know ...)
 - any non-trivial patches require copyright assignment to Ximian Inc.
 - all code needs to be ansi c
 - camel code needs to be multi-thread safe (or at least friendly)
 - camel uses its own simple c-based object system

Hmm, i dunno what else, ask away i guess?

Cheers,
 Michael

PS I posted a sort of a camel todo for evolution 1.6 about a week ago to
this list, which covered some of this stuff, although lightly.