Various design questions

Werner Koch
Mon Oct 22 10:00:01 2001

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