Re: [Evolution-hackers] S/MIME support



On Wed, 2003-07-09 at 01:54, Not Zed wrote:
> FWIW, i would like to see this done via a plugin system, so a gpgme
> backend might be a possibility.
> 
> The GPL thing isn't insurmountable, although inconvenient.  It could be
> used via a daemon/pipe.
> 
> If gpgme can come up with a common frontend api (does it?) with
> different backends, then so could camel.

Yes, gpgme has a common frontend api with OpenPGP and CMS backends using
gnupg and gpgsm. One of my points is that gpgme already does this, and
for camel to do it without using gpgme is basically code/effort
duplication. Plus, I believe one of gpgme's goals is to work with
different versions of gpg, so even if the command line options change,
code using gpgme wouldn't have to.

> 
> 
> On Fri, 2003-07-04 at 03:14, 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.
> > 
> > > 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
> > >
> > 
> > _______________________________________________
> > evolution-hackers maillist  -  evolution-hackers lists ximian com
> > http://lists.ximian.com/mailman/listinfo/evolution-hackers




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]