[Kde-pim] [Differential] [Commented On] D2324: Introduce Kleo::KeySelectionCombo class

dvratil (Daniel Vrátil) noreply at phabricator.kde.org
Tue Aug 2 11:02:03 BST 2016


dvratil added inline comments.

INLINE COMMENTS

> aheinecke wrote in keyselectioncombo.cpp:161
> Yes Libkleo should imo provide a configurable new Key generation dialog. But I don't think you need a dialog at all from KMail because you can take the Name / Mailbox from the Identity configuration.

If I ditch the S/MIME key generation, then we don't (just need some progressbar).

> aheinecke wrote in keyselectioncombo.cpp:174
> With GnuPG 2.1.12 or so we could use a Quick Gen Key, but as we don't want to rely hard on such a new version we need these params :-(

Right, but there should be a class in libkleo where you setKeyType(), setKeyLength(), addSubKey()  etc. and then call generate() and the class would assemble the XML internally and call the generation job. I've spent way too much time understanding and stripping down the code from Kleopatra's wizard to get this working.

> aheinecke wrote in keyselectioncombo.cpp:176
> I don't think this "Inline Keygen" can work for S/MIME in KMail this way as a new S/MIME Certificate only generates a CSR that has to be exported and sent to a Certificate Authority for signing. This is out of scope currently as it creates loads of problems usability wise.
> 
> I think for S/MIME the common case is that you either get your certificate handed to you by your CA or Administration and have to import it or that you start a dedicated tool (Kleo) to work this out.

I can remove the option for S/MIME then. Alternatively we could have "Import" action instead of "Generate new key pair", but that adds even more complexity.

> aheinecke wrote in keyselectioncombo.cpp:411
> This is something I always found annoying in the old selection that it showed you even keys that you could not select. We should imo only include keys with ultimate UID Trust as these are what GnuPG thinks are "your own keys" and you are currently selecting your own keys.
> 
> For the super corner case that someone wants to configure not his / her own key for an E-Mail address. (I'm maybe thinking about some "support at foo.bar" with a shared support signing key that does not have ultimate trust they can edit the configuration of KMail.
> 
> To quote Björn "We should design for the 95% and not the 5%".

I don't think that Bjoern's argument should ever lead to "they can modify config files manually". I'm thinking of adding "More keys..." option that would open the regular KeySelectionDialog where you can select whatever you want. Not sure how to do it yet though.

> aheinecke wrote in keyselectioncombo.cpp:464
> This can be a ridicoulously slow job:
> 
> e.g on my very high performance system (admittedly with a fairly large keyring):
> time gpg2 -K
> gpg2 -K  3.85s user 0.13s system 98% cpu 4.032 total
> 
> Because due to the Architecture GnuPG has to go over every public key and ask the gnupg-agent through IPC if he has a secret key for this public key. On slower Systems or if a TrustDB Update (which gnupg does automatically) is involved seen this job to take over 30 seconds. That's why Kleopatra now has a "Keycacheoverlay" to similarily to KMails Akonadioverlay disable widgets and show a "Loading Certificates.." Progress bar.
> I've already complained to upstream about this and they might fix this in the future.
> 
> But in this widget this would result in a noticable delay between widget shown and entries visible. With GnuPG versions > 1.4 < 2.1.6 this job could even take an infinite amount of time as it resulted in CRL Checks for each S/MIME Certificate.
> 
> This could be solved by putting the keycache into libkleo so that it can be populated before in the background.

I can work on that, but in a separate patch, that would be out of scope for this review IMO. On my rather small keychain (i.e. a keychain that most people have?) this is rather fast (no noticable delay), so it should be good-ish for now (?)

REPOSITORY
  rLIBKLEO PIM: Kleo Library

REVISION DETAIL
  https://phabricator.kde.org/D2324

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: dvratil, aheinecke
Cc: kde-pim, spencerb, dvasin, winterz, smartins, vkrause, mlaurent, knauss, dvratil
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/


More information about the kde-pim mailing list