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

List:       kmail-devel
Subject:    Re: PGP 2 support
From:       Ingo =?iso-8859-1?q?Kl=F6cker?= <ingo.kloecker () epost ! de>
Date:       2001-10-30 8:00:49
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 30 October 2001 07:52, Karl-Heinz Zimmer wrote:
> Excuse me for intefrering here but unfortunately the Bad Thing[TM]
> seem to have happened here:
>
>    Our (mine and others of the Ägypten team) somewhat unhappy way
>    of explaining our concept _did_ lead to a misunderstanding both
>    superfluous and frustrating:
>
>    Please believe me that it is _not_ our idea to tell you what you
>    have to do!

O.k., I guess I overreacted a little bit yesterday.

>    What we would like to do concerning the status quo is simple:
>
>    *  Take the current PGP related implementation in KMail and have
> it - without taking away anything - encapsulated in a little Plug-In.
>
>    *  Test this Plug-In to make sure everything works fine.
>
>    *  Remove the current PGP related implementation from KMail,
>       but _do_ _not_ remove the little PGP Plug-In!
>
>    * Design our "Gpg Plug-In"
>    ...
>
>    By doing we will end up having _two_ options: either use the old
>    solution and be happy with it OR use the "Gpg Plug-In".

This sounds like a good solution. But shouldn't you call your "Gpg 
Plug-In" "Sphinx Plug-In" instead?

>    Switching from one to the other is extremely easy: just one mouse
>    click on the Plug-In registration page of Settings/Configure
> dialog.

Maybe it has to be even easier, e.g. depending on the identity the user 
uses. The reason for this is that some user's might have to use S/MIME 
for mail exchange in their company while they want to use OpenPGP for 
their personal mail.

> Also, to really make sure we are _not_ telling you what you 'should'
> do, there is another option that you of course are free to choose:
> you could still add functionallity to the existing PGP solution and
> let users access this by choosing the traditional way (by selecting
> that Plug-In).
>
> So there are two important things:
>
> A) We will not remove anything!

I did never think you would. ;-) At least I wouldn't have let you.

> B) Even if the new "Gpg Plug-In" is going to cover most of the
>    PGP support that is currently in KMail it will _not_ do things
>    that encourage users to software restricted by patents.

I understand.

> IMHO Werner is allowed to decide how he is going to enhance Gpg.

Of course.

> There are actually two ways how to prevent KMail from loosing
> functionality: either the way we will go anyway (by transforming
> the status quo into a Plug-In) or the way mentioned by Werner
> in another mail: just write a little wrapper emulating GnuPG -
> this would be an easy job.

IMO the plug-in solution is better because it's much more flexible. I 
doubt that it would be that easy to write a wrapper because this 
wrapper would have to convert all PGP error messages to GnuPG error 
messages and I don't think there is a 1-to-1-correspondence between 
them.

> > remove support for other encryption protocols/programs.
>
> I hope is was successfull in making clear that we do _not_ intent to
> do this - nor did we ever!

Yes. ;-)

> > If you don't like it please feel free to make your own version of
> > KMail.
>
> Ingo, please, there is no need to address us like this: beginning
> with our very first mail here we tried to make clear that we want to
> be both helpfull and cooperative to/with the community.

Sorry for my overreaction.

> We will definitely not fork, this option just is non-existent for a
> project that is going to _support_ the free software community.
>
> But what we do (as you have the same right) is 'fight' for our
> arguments and I am sure we will find good compromises where ever our
> opinions collide.

Now that our 'fight' is over we should get productive. ;-)

> > After all KMail is a piece of Free Software although it supports
> > the usage of non-free software which AFAIK isn't forbidden by the
> > GPL, is it?
> >
> > Nobody of us likes patented algorithms -- well, at least me -- so
> > please don't get us wrong. But we are not going to remove support
> > for PGP 2 just because you have a problem with this.
>
> And we do _not_ force you to do so!
>
> All we do is saying: /We/ are not going to actively support that, but
> we keep it as it is so _you_ are free to continue supporting it.
>
> > Sorry, for being rude but this discussion ends here.
>
> Are you sure that this 'end' is neccessary?

Actually I meant the 'discussion' about removing the PGP 2 support. I 
guess we cleared this up now.

> We are still in the middle of the discussion: this mail of mine just
> tries to make our position clear because I found it somewhat
> difficult so interpret our different postings correctly.

So let's continue the discussion of the implementation. The plug-in 
solution sounds really promising. But how should it be implemented. IMO 
it should be made as generic as possible so that even programs like 
KOffice can use encryption through this plug-in. That means that we 
need high-level S/MIME resp. PGP/MIME support for KMail (and mutt) and 
low-level signing/encryption support for all programs which would like 
to use signing/encryption.

Regards,
Ingo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE73l40GnR+RTDgudgRAhWRAKDiuSZwJAU8+arfTjrhfruYVRK9NACeKbuu
5VDxR66E1IKY+RdwWtlP0DU=
=PKYY
-----END PGP 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]