On Thu, 2003-07-03 at 13:44, Jacob Perkins wrote: > Why not use gpgme and gpgsm? gpgme's abstraction works over gpgsm and > gnupg (and maybe more in the future), so implementing s/mime with gpgme > could also make the pgp code simpler. There is a working plugin for KMail > which uses gpgme/gpgsm, and balsa and sylpheed both use gpgme for pgp > support. The existing interfaces could still be kept, only the backend > code would have to be changed.
2 words: licensing issues :-) we can't use gpgme because it is GPL. Jeff > > > 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. > > > > -- > > Jeffrey Stedfast > > Evolution Hacker - Ximian, Inc. > > [EMAIL PROTECTED] - www.ximian.com > > > > _______________________________________________ > > evolution-hackers maillist - [EMAIL PROTECTED] > > http://lists.ximian.com/mailman/listinfo/evolution-hackers > > -- Jeffrey Stedfast Evolution Hacker - Ximian, Inc. [EMAIL PROTECTED] - www.ximian.com _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
