Various design questions

[Werner Koch]

On Sat, 20 Oct 2001 14:52:40 -0400, George Staikos said:

> signing in Reaktivate.   This also raises another question:  When a user 
> imports a new key via the GUI, which database does it go into?  The GPG one 
> or the KDE one?  Or both?  Or do we prompt the user?  I guess by using the 

Just store them in both if this makes sense for you.  

BTW, for secure usage of SSL you also need to handle revocations and
you should not wait for the issuer to publish one but check yourself
whether a CA has revoked something.  If you are using OpenPGP keys you
probably want to recalculate the WoT from time to time and of course
handle revocations too.  For me it makes pretty much sense to
centralize this.  OTOH, it may tak a while until this is implemented
becuase it is outside the scope of most projects.

> md5 fingerprint it's easy to remove duplicates so that isn't a problem.  

A database should never allow duplicates.


On Sat, 20 Oct 2001 20:56:25 +0200, Bernhard Reiter said:

> it looks like there is soem discussion about the same topic going on
> the kmail list.

Can we please continue to discuss KDE related things on kmail@kde.org
and reserved this list for a backend and maybe discussion on other MUAs?


On Sat, 20 Oct 2001 15:07:21 -0400, George Staikos said:

>    If it doesn't require one to link GPG libraries into the app in order to 
> access the database, and if it's easy to obtain all forms of certificates 

data formats and code should go hand in hand.  So to access a future
key database you probably want to use the provided API - this may be a
low evele API and not the full blown gpgme thing.

> certainly desirable.  Also we need the ability to store entire certificate 
> chains.  Right now I use K[Simple]Config because it's easy and it's standard 

And you have to do all the other key management tasks.

>    However I must warn that I no time available to modify the KSSL code to 
> make use of a different library any time in the near future.  The code in 
> KSSL is ugly, mostly due to trying to merge KDE with OpenSSL (not a fun task 

Wait a while until GnuTLS is usable.


On Sat, 20 Oct 2001 15:00:09 -0400, George Staikos said:

>   Ooops.  Your mailing list doesn't put itself in the reply-to :)  I assumed 
> it did.

For sure not, we are honoring privacy issues (if only Gnus would do
the same ;-)

>    My point is that I have already implemented this (for the X.509 stuff) in 
> KDE.  We have to have a KDE specific GUI and backend for this due to SSL and 

You have a full-blown X.509 management in KDE?  I wonder why Kalle did
not tell us.

> codesigning requirements.  We don't want to have to link GPG _and_ OpenSSL 

You want to do code-signing in KDE?  This is a horrible difficult
task which actually can only be untertaken with support of the OS
kernel and even if you could do that with Linux you won't gain much
because Linux makes no strong distinction beween root and kernel mode.
I say, this has to be designed from ground up.

> installed at all.  As I mentioned in the previous mail, one possible solution 
> is to merge the databases at runtime.  It's easy to strip out duplicates but 

Keeping duplicate data is one of the worst errors you can do, it often
seems to be manageable but over the lifetime of the system it tends to
get more and more complicated and error prone.  Better prepare early
to use just one DB.


On Sun, 21 Oct 2001 09:59:12 -0400, George Staikos said:

> On Sunday 21 October 2001 07:43, Markus Montkowski wrote:

Huh, where?

>> but wouldn't the best approach be to keep the management and the GUI appart
>> from each other

Sure.

>> and use Dynamic runtime linking? Each Module should export some well
>> defined Functions like

The unix way is to separate services into different processes.  This
provides a cleaner interface, speeds up execution of moules a lot and
is more secure (smaller modules have less errors).

>> - Command(ULONG ulCtx, ULONG ulCommand, ULONG ulParam1, ULONG ulParam2)
>> Used for all the management calls etc.

Argg.  This is a error prone interface which should only be used in
very certain cases (e.g. ioctl(2) but even then the libc should
provide function style wrappers.) 

>> All the key DBs are shown in a Treeview like control. If you are at the
>> root of all DBs you would import

Again, keeping a key at more than one place is a Bad Thing.

> We have worked long and hard for consistency in KDE.  I don't want to see 
> this inconsistency happening, and as I said, I certainly won't be coding 

George, please remember that there is more than KDE.  KDE is just one
big application pool but there are others, GNOME, xfce, Emacs and all
the other environments which don't stick to a particular Service set
except for Posix.  Don't get lock into the Windows trap - even MS
figured out a long time ago that there must be separation between the
GUI and the services provided by an OS.  There are not so few matured
interfaces available - trying to create another will be futile, so lets
stick to well matured interfacs.  Posix and SysV are well matured (at
least we know the problems).

Ciao,

  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus