GnuPG supports OpenPGP keys with ECC algos. These should be displayed correctly as ECC. Currently subkeys for ECC are shown as ”Unknown subkey“ which is a bit misleading because GnuPG knows about them and can even create them with the --expert option.
Created attachment 101135 [details] NON-PRODUCTION PATCH - implement recognition of ECC key types Attached a patch (against v16.08.1) which makes it at least recognize the key types. But I strongly recommend *against* including the patch as-is. The _gpgme_map_pk_algo function I threw in there is basically just a rip of the non-exported function of the same name from here: https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=commitdiff;h=c4b6b35bfa98e478f1d13f4ce3e664771f2604c2 It does the job, but KGPG shouldn't be responsible for converting OpenPGP algorithm identifiers into GPGME algorithm identifiers. It seems to me that KGPG should just be using the key listing APIs: https://www.gnupg.org/documentation/manuals/gpgme/Listing-Keys.html#Listing-Keys But it looks like KGPG doesn't link to gpgme and only uses the gpgme_validity_t type from gpgme.h? This patch also does not take care of adding ECC key generation, and there are 9 different curves to choose from, so that means at least another dropdown in the key generation dialog. ;)
Oh, I forgot to mention. Another place where my patch is useless is showing which curve is being used. I've seen some other GPG frontends replace the "size" column with a more descriptive "strength" column with values like "dsa1024", "rsa2048", "ed25519", and "secp256k1". It seems like a good idea to me since the bit length means nothing without knowing which algorithm is being used.
Created attachment 101139 [details] implement display of "strength" instead of "size" Along with the previous patch, this implements a display of "strength" as I described in my last comment. Screenshot of this in action here: https://www.uplinklabs.net/files/Screenshot_20160917_050857.png Some of the curves have horrendously long names, so I'm not too fond of that. But it does work at least...
Your approach looks sane so far. Please post patches to git.reviewboard.kde.org, that is the better suited tool for patch discussion.
And please base any feature patches on the frameworks branch if possible, if not, then use master.
I submitted the first patch to review board. It didn't like the second one because it depends on files that were changed in the first one: The specified diff file could not be parsed. Line undefined: fatal: git cat-file 7a4f1659842222e2537cd893058fbb35c9c67c2c: bad file I could squash the patches together but that feels naughty.
Squashed patch up for review here until I find out how to make ReviewBoard cooperate: https://git.reviewboard.kde.org/r/128931/
Git commit 65514177e6b9d096b5f6a822a1699e474d791f03 by Andrius Štikonas. Committed on 01/10/2016 at 12:36. Pushed by stikonas into branch 'frameworks'. Fix compilation with older versions of gpgme. M +8 -0 core/convert.cpp http://commits.kde.org/kgpg/65514177e6b9d096b5f6a822a1699e474d791f03
Andrius, that commit isn't right. You can't use #ifdef on an enum value. It would only be guaranteed to work properly with preprocessor macros.
Something like this would work though: diff --git a/core/convert.cpp b/core/convert.cpp index 1f30739..2939767 100644 --- a/core/convert.cpp +++ b/core/convert.cpp @@ -28,10 +28,10 @@ #include "kgpgsettings.h" // Backport of gpgme enums from version 1.7.0 -#ifndef GPGME_PK_EDDSA +#if GPGME_VERSION_NUMBER < 0x010700 #define GPGME_PK_EDDSA 303 #endif -#ifndef GPGME_PK_ECC +#if GPGME_VERSION_NUMBER < 0x010500 #define GPGME_PK_ECC 18 #endif