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

List:       kde-pim
Subject:    Re: [Kde-pim] KMail & GPG integration
From:       Stefan Gehn <mETz81 () web ! de>
Date:       2006-05-04 18:41:50
Message-ID: 200605042041.50336.mETz81 () web ! de
[Download RAW message or body]

Am Montag, 1. Mai 2006 01:57 schrieb Ingo Klöcker:
> On Saturday 29 April 2006 14:46, Stefan Gehn wrote:
> > I'm currently working on my bachelor thesis which is centered around
> > usability and security. For the practical part I'm planning to
> > improve gpg-integration in kmail.

Just some further notes about my thesis:
- centered about the idea of making security features usable and trying to 
convince its readers that hiding security away (as done with gpg IMHO) is not 
needed
- timeframe: usability tests around june 15th, finish thesis at the end of 
june

I know that this is not a long time (3 months are the usual timeframe here) 
but I don't really have another option if I want to continue with my cs 
master afterwards.


> > Ideas so far (in no particular order and probably not detailed enough
> > yet):
>
> I think the first step would be to make kgpg use libkleo (or at least
> gpgme) unless this has already been done. Using gpgme is the only way
> to guarantee that applications using GnuPG will still work with later
> versions of GnuPG.

I looked a bit into kgpg code and so far it looks like kgpg is directly 
parsing gnupg output :/

Unfortunately I'm not sure if I have the time to change the backend behind 
kgpg given my current timeframe.

Eventually, I will simply allow starting kgpg from kmail and do the rest 
(wizard, agent setup, key viewing) inside libkleo.


> > - use kgpg from kmail (could be implemented in libkgpgp, could as
> > well be in a lib of its own) for displaying key-information, creating
> > keys for accounts and more
>
> For displaying key-information it would make sense for KMail and KGpg to
> use the same library. Maybe in libkleo/ui (which is hidden in
> certmanager/lib/ui in branches/KDE/3.5/kdepim)?

Yes, especially since the current kgpg-dialog doesn't look very appealing yet.


> > - allow user to manually fetch missing keys from kmail (could use
> > kgpg for progress-gui and results)

Question for kmail-devels: where are the sign/encryption html-boxes hidden in? 
I guess making the key a clickable link or replacing it with a 16x16 icon 
would be nice for users.


> > - make key-creation dialog in kgpg a wizard that explains things
> > (like "why it's good to upload the public key")

Again I'm not sure if creating that inside libkleo or for kgpg is the way to 
go.


> > - gpg-agent setup through wizard, either as part of a lib or kgpg
> > (kmail needs gpg-agent for encrypting)
>
> How much setup is necessary? I think the only problem is that a suitable
> gpg-agent.conf has to be added to ~/.gnupg and a simple file containing
> the command line for starting gpg-agent has to be added to ~/.kde/env.

For a recent debian install one only has to enable gpg-agent in gnupg.conf.

Btw, does gnupg have any tools to change things in gnupg.conf and 
gpg-agent.conf? gpgconf doesn't list parameters like "pinentry-program" 
or "use-agent" on my machine.


> > - hide all the hex-stuff (key hashes etc.) if possible (thunderbird
> > for example uses icons in its mail-view instead of hex-values)
>
> I'm not sure how this would look. Please attach a mockup or a screenshot
> of tb.

Attached is a screenshot showing Thunderbird + Enigmail.
I think having smaller sign/encrypt icons in the headers of these colored 
boxes around mail-parts could be nice. Clicking on the icon would then show 
detailed information, like the key used for signing or maybe more (again 
using the ui parts from above).


> > - maybe make asking for passphrase an async process, right now kmail
> > freezes while pinentry-qt asks for my passphrase (is this possible?)
>
> Yes, this should be done, but I don't know how easy/difficult it is.

If anybody knows about this, please enlighten me :)
So far I only found a reason for the X11 keyboard-grab, it's meant to avoid 
typing the password into another window or being sniffed by another user 
having access to this X-session.
I don't think the second argument still holds (usually X.Org installs do not 
listen on TCP anymore nor do they allow connections from other users by 
default) and for the first we have kwin focus-protection.

If one could make a pinentry-kde out of pinentry-qt we could get rid of the 
grabbing but the freezing is still a problem then. I guess it's caused by 
some blocking call into gpg-libs (unfortunately the grab keeps me from using 
gdb to find the cause).


> > - make messageboxes about missing keys more helpful, currently they
> > tell you to open the account-settings if you don't have a key
> > assigned but they don't allow you opening it right away
>
> Yeah, that's a pretty annoying bug. I think the problem is that we
> currently can't open the configuration dialog with a specific page. Or
> maybe we should open just the relevant account settings dialog?

Account settings would be fine. All messages that I encountered so far refer 
to account settings anyway. Any hints on where such messages are to be found?



> libkpgp was used in the past and is still used for dealing with
> clearsigned messages (AFAIK). It should eventually be dropped
> completely.

Does clearsigned mean inline-pgp without mime?

To be honest, finding something in the multiple libkleo backends and having 
libkgpg complicates things quite a bit :)


> > - can kmail/libkgpg drop the non-gpg-agent functionality for signing,
> > I think it's VERY confusing that signing works but encryption does
> > not unless gpg-agent is setup properly
>
> Yes, that's confusing. OTOH, we should rather make KMail automatically
> start gpg-agent if it's not running and we should get rid of the
> gpg-agent-less workaround code for signing.

Exactly. Can one actually start gpg-agent if needed? AFAIK it has to add a 
global env-var (GPG_AGENT_INFO) for working properly (it's a path to some 
socket-file I think).


> > - why is the account-wizard only shown on first start? I'd like to
> > add an option for key-creation/selection to it, would be way cooler
> > if people could also use that for accounts created _after_ first
> > start
>
> Yes, the wizard should probably used for every account creation (with an
> easy way to skip it and go to the normal config dialog).

whom to ask about the current wizard? I'm not sure how much it depends on 
being displayed only on first-start. Otherwise adding a simple "Add 
account..." in prefs-menu would already help and keep manual adding in its 
current place (i.e. prefs dialog).

Of course these two ways of adding accounts would have to be unified later on 
but for now I prefer to keep my tasklist small.


> The certificate manager is nowadays called kleopatra and the gpg log is
> kwatchgnupg (which I already mentioned above). Maybe those two
> applications are not installed on your computer. BTW, kleopatra and
> kgpg should ideally be merged in some way. Currently, kleopatra is
> (mostly ?) restricted to S/MIME certificates.

Yes, certmanager is not installed, libkleopatra is. kwatchgnupg should really 
be moved out there and only depend on libkleopatra at most (it only seems to 
use it for interfacing with gpgconf in a clean way).

Merging kleopatra and kgpg indeed could solve things, we'd only have one 
central place for viewing all gpg keys in the system. I didn't have a look at 
kleopatra yet and I guess key-management will have to wait for now if I want 
to get things finished.


Summary so far:
-- libkleo --
 ui to display gpg-keys
 ui to create own key
 ui to setup gpg system (i.e. agent and general config if needed)
-- kmail --
 allow to view sender-keys from mail-view
 gpg and key setup from account wizard if needed


Btw, I have no problem with improving and porting all this to KDE 4 after my 
thesis is done but for now I have to focus on tasks that are realistic within 
the given timeframe.

Bye,
Stefan aka mETz

["tb-enigmail.png" (image/png)]

_______________________________________________
kde-pim mailing list
kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/

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