Re: [Evolution-hackers] S/MIME support

["Jacob Perkins" <jap1 users sourceforge net>]

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.
> fejj ximian com  - www.ximian.com
>
> _______________________________________________
> evolution-hackers maillist  -  evolution-hackers lists ximian com
> http://lists.ximian.com/mailman/listinfo/evolution-hackers
>