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