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

List:       kmail-devel
Subject:    Re: S/MIME
From:       Bernhard Reiter <bernhard () intevation ! de>
Date:       2003-09-04 18:40:10
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Monday 25 August 2003 22:06, George Staikos wrote:
>    Well the biggest problem right now is that the "plugin" architecture is
> only designed to support one plugin: the gpg based one. 

I'm not sure this can ever be changed for the crypto functionality.
It is likely that its integration with KMail code will be deep.
Thus calling this "plug-in" is giving the false impression that there
could be a one interface for S/MIME or OpenPGP crypto code.
It is more like a prepared loadable module.

>    I suspect we will have a fully working PKCS#11 sometime over the next
> year and it would be nice if our plugin worked so we could use it.

As far as I've understood PKCS#11, this interface not useful 
for Free Software applications, because we can more directly access
tokens like ICCs. The access itself is not posing the problem
and will not just make the tokens work.
You need to control the devices and that is not part of PKCS#11,
but will be the problem.

>    I still believe that this licence complaining is a load of crap.  If the
> licencer and the licencee both agree that the licence is acceptable to
> eachother, then that must be sufficient.  

That is being naive.
You can't  prove that "silent" agreement in court
thus making anybody depending on the change of the mind 
of any of the right owners (which there are many).

> 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.

It is running in the same address space if I understand that technical
construction correctly. And even if it doesn't, it most likely will
be a derived work, because of the unique depencency.

>    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.

Beside the licensing problem this most likely will not make KMail 
SPHINX (German subset of Ägypten) compatible, because of details
and official testings needed.


["smime.p7s" (application/pkcs7-signature)]

_______________________________________________
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]