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. _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
