[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: S/MIME
From:       Stefan Rompf <srompf () isg ! de>
Date:       2003-08-27 16:04:48
[Download RAW message or body]

Am Montag, 25. August 2003 22:06 schrieb George Staikos:

>    Well the biggest problem right now is that the "plugin" architecture is
> only designed to support one plugin: the gpg based one.  This needs to be
> fixed so that it is KDE standardized and freedesktop XDG compliant.  the
> XDG spec (I think that's the right spec) defines the location for plugins
> to be installed, for instance.

Also, the crypto plugin API is very much tied to Aegypten. This makes it 
possible to use the Aegypten plugins outside KDE too, but limits the KDE 
features the KSSL plugin can use, for the simple reason that the API does not 
always pass all information needed.

I already thought about a direct integration of S/MIME into KMail, but I'm far 
to unfamiliar with the code right now. And the weather was too good this 
summer ;-)

> eachother, then that must be sufficient.  KMail will not be linking against
> OpenSSL (it never does, really, though it does use KSSL).  The plugin can
> be in a separate directory.  At that point, the only person concerned must
> be the plugin author.

Well, actually KOpenSSLProxy is the bad piece of code that uses openssl ;-) Do 
you have some results with the patent issue Alan Cox mentioned?

>    If the plugin system can actually be turned into a *plugin* system and
> not a hardcoded library path to ~, then I propose we finish up the KSSL
> S/MIME plugin and commit it to kdepim or kdeaddons.

Do we want to meet the KDE3.2 schedule for this? From my point of view, the 
KSSL plugin is stable, but using it is still a bit raw:

1. There is no possibility to assign a S/MIME certificate to a kmail identity, 
as with the GPG executable interface. Therefore, the certificate to use has 
to be selected from the outside (currently default cert from KDE control 
center)
2. Consequently, only one certificate can be used, also for receiving mail
3. We need a tool to download certificates from websites (application/x-x509-
email-cert). I have such a tool, just need to add a nice user interface ;-)
4. Displaying the certificate chain does not work yet
5. We need the email certificate authorities in the default CA list of KDE. 
Trivial.
6. The control center became a bit slow now that is has to handle about 100 
peer certificates on my system.

I could fix 3, hopefully 4, 5 and without too many problems. What do other 
people think, what would be most important before (or even if) we consider 
moving the plugin?

Stefan
-- 
"doesn't work" is not a magic word to explain everything.
_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail
[prev in list] [next in list] [prev in thread] [next in thread]