Fixed in 4711a1e1.

The algorithm I'm using now to detect the best key from a locate-keys result is
(Q_FOREACH just means "iterate over all elements in this list"):

Key keyC; /* The key candidate */
UserID uidC; /* The uid candidate */
Q_FOREACH (const Key k, keys) {

if (canEncrypt && !k.canEncrypt()) {
    continue;
}
/* First get the uid that matches the mailbox */
Q_FOREACH (const UserID u, k.userIDs()) {
    if (QString::fromUtf8(u.email()).toLower() == mailbox.toLower()) {
        if (uidC.isNull()) {
            keyC = k;
            uidC = u;
        } else if ((!uidIsOk(uidC) && uidIsOk(u)) || uidC.validity() <

u.validity()) {

            /* Validity of the new key is better. */
            uidC = u;
            keyC = k;
        } else if (uidC.validity() == u.validity() && uidIsOk(u)) {
            /* Both are the same check which one is newer. */
            time_t oldTime = 0;
            Q_FOREACH (const Subkey s, keyC.subkeys()) {
                if ((canEncrypt && s.canEncrypt()) && subkeyIsOk(s)) {
                    oldTime = s.creationTime();
                }
            }
            time_t newTime = 0;
            Q_FOREACH (const Subkey s, k.subkeys()) {
                if ((canEncrypt && s.canEncrypt()) && subkeyIsOk(s)) {
                    newTime = s.creationTime();
                }
            }
            if (newTime > oldTime) {
                uidC = u;
                keyC = k;
            }
        }
    }
}

}

The helper functions to check if a key / subkey / uid is ok are just:

static bool keyIsOk(const Key k)
{

return !k.isExpired() && !k.isRevoked() && !k.isInvalid() && !k.isDisabled();

}

static bool uidIsOk(const UserID uid)
{

return keyIsOk(uid.parent()) && !uid.isRevoked() && !uid.isInvalid();

}

static bool subkeyIsOk(const Subkey s)
{

return !s.isRevoked() && !s.isInvalid() && !s.isDisabled();

}

Quoting Ben McGinnes (2016-05-11 19:54:21)

On Wed, May 11, 2016 at 12:44:00PM +0000, Justus Winter via BTS wrote:

Justus Winter <justus@g10code.com> added the comment:

I have integrated the Python bindings into our build system. See branch
'justus/pyme3'.

Open issues:

• (API) Change the name of the Python module. Currently it is named 'pyme',

shouldn't we use 'gpgme' instead?

No, simply because other (abandoned) attempts at writing wrappers for
GPGME already exist in the Python ecosystem. If we rename a module to
match the name of an existing one this will break things somewhere.
It also makes us no different from poor Isis Lovecruft who selected
the name gnupg for her fork of python-gnupg, but the original was
always imported as just gnupg so when she increased the version number
of her fork she broke a *lot* of things in other people's code.

That's also why the entirely new thing I've called GPyGME, not just to
play word games with Pygmy, but also because the name is not used by
any existing Python module.

I have integrated the Python bindings into our build system. See branch
'justus/pyme3'.

Open issues:

• (API) Change the name of the Python module. Currently it is named 'pyme',

shouldn't we use 'gpgme' instead?

• (API) One has to hand 'bytes' objects to pyme where 'char *' is expected. We

should make SWIG magically encode strings as utf-8 instead.

• Documentation. Needs to be build, likely updated, and installed. Ben was

thinking about using another tool for this. Needs investigation.

• No test suite.
• 'lang/python/examples/simple.py' segfaults.

This will be useful for GnuPG itself. For example, currently in
gnupg/agent/command-ssh.c, we have a function ssh_receive_key which compose a
private key from 'ssh-add'. With this API, it will be cleaned up.

Justus, can you take care of this?

Shoul all be done for 1.7.0.

Should be solved now: Use Libgpg-error 1.22 and GnuPG 2.1.12.

I have implemented iconv in libgpg-error master (commit 1cd1ddb). This is a
stripped down version of win-iconv where I removed the feature to load another
libiconv and disabled the mlang.dll (whatever this is) for now.

With gnupg master commit bd4d656 tehre is no more need for libiconv for Windows.

I think I was confused by the fact that I didn't use ssh-add to add the key and
I didn't realize that I could add it manually to sshcontrol. I did that and it
now works as expected. Sorry about the noise.

Although maybe it would be nice to be able to make 'confirm' the default for
keys which are not listed in sshcontrol. But that's a very minor thing.

I've now pushed a patch to the GTK variant based on werner's original work with
the message box and the string button labels.

I was unable to get the tab order working correctly so that the visibility
button comes last in GTK. I've tried it with gtk_container_set_focus_chain but
it did not work as expected. When set on the wvbox it disabled tab changes
altogether. When set on the cbbox or bbbox it somewhat worked (e.g. when I
removed a widget from my list it was no longer tabbable) but it would not add
the repeat edit and the visibility toggle button although both were part of my list.
Probably a problem because of the sublayouts?

I noted this in the code so if someone wants to change that you are welcome :-)

Am Donnerstag, 14. April 2016 16:24:59 schrieb Andre Heinecke via BTS:

But from the discussion here and back then I took that draft to be no
longer up to date and that the MessageBox Question approach with small icon
buttons is not wanted.

I know your first draft.

But from the discussion here and back then I took that draft to be no longer up
to date and that the MessageBox Question approach with small icon buttons is not
wanted.

I also don't know where we agreed that an Eye icon is a bad idea for this action.
This icon in similar to the one of the Windows Login screen and the same one
used in KDE. So it is recognizable for this action.

If you strongly favor the Message box variant I can change it to that.

No string changes in gpg-agent please.

I though we agreed that a watching eye is not a good icon for various reasons?

For the GTK version I already proposed a different layout:
it is still available at https://wiki.gnupg.org/ScratchWK . That fallback
solution tales away to much real estate

Better screenshot of the fallback showing a real call by gpg-agent instead of a
"getpin"

Neal: I've commited this with: 71b51e02cf20174ba7144765e985f7e889eaa429

The Make passphrase visible is in the tab order after the line edit. I don't
know how to best change this in GTK and the "Save passphrace using libsecret"
button would have the same problem.

I don't think it's a real problem though as you would have to tab + space to
make the password visible. Tab + Enter would just accept the dialog.

If you think this ok you can set this issue to resolved. You can also change the
setting you mentioned in T2139 (neal on Dec 07 2015, 10:09 AM / Roundup) . I don't know how. :-)

We might want to change the strings in gpg-agent though. I would prefer: "Show
passphrase" instead of "Make passphrase visible".

Fallback variant. (Qt5 Version with XDG_CURRENT_DESKTOP=GNOME)

The checkbox comes after the cancel button in the Tab order and will not
activate when pressing enter.

This is how I'll add it to the GTK variant now.

I've implemented this for Qt now.

The Qt5 variant with breeze icon theme looks like the attached screenshot. This
is how it will look on Windows and for KDE plasma 5 users.

If the Qt version is too old (The API for the line edit action was added in
Qt5.2) or there is no icon for the visibility actions it falls back to a textual
checkbox.
This also avoids licensing problems with the icons as the icons are loaded
through QIcon::fromTheme.

Do you mean that sshcontrol is not considered if the currently plugged in card
is used?

And there is also the new

  $ gpg --quick-gen-key "Otto Normalverbraucher <otto@example.invalid>"
  About to create a key for:
      "Otto Normalverbraucher <otto@example.invalid>"

  Continue? (Y/n)

which avoids almost all questions. Whether to set an expiration date by default
is a different question and is connected on how a key can be revoked.

Although the patch is not very intrusive to other parts of GnuPG,
I do not like it for several reasons:

• Armored is detected by the file's suffix. That is not the Unix way.

• open and close is used - we should avoid that in new code. Always use es_ functions for better portability.

• There is new function to create some temp dir despite that we already have such functions elsewhere. I have not seen the immediate reason for it.

My suggestion was to read the file into an estream object and change
the dearmor and keydb_add_resources to be able to work with it. There
is a unarmor_pump_new function which could be a starting point.
Granted, this would be a much more intrusive change and thus I doubt
that it is useful to spend too resources on it.

Can you please back out that commit.

BTW, please do not put a "cleanup" label in the mid of a function and
according to GNU standards initialized variables deserve separate
lines and statements.

Thanks for your suggestions. We have simplified the key generation process, do
you mind to re-evaluate it?

% gpg2 --gen-key
gpg: WARNING: unsafe permissions on homedir
'/home/teythoon/repos/g10/local/gnupghome'
gpg (GnuPG) 2.1.12-beta119; Copyright (C) 2016 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
Note: Use "gpg2 --full-gen-key" for a full featured key generation dialog.

GnuPG needs to construct a user ID to identify your key.

Real name: Otto Normalverbraucher
Email address: otto@example.invalid
You selected this USER-ID:

    "Otto Normalverbraucher <otto@example.invalid>"

Change (N)ame, (E)mail, or (O)kay/(Q)uit? o
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: key 81F88C88 marked as ultimately trusted
gpg: revocation certificate stored as
'/home/teythoon/repos/g10/local/gnupghome/openpgp-revocs.d/5FB9D2A5255C94E3D06B5B563C8167E481F88C88.rev'
public and secret key created and signed.

gpg: checking the trustdb
gpg: public key of ultimately trusted key 909DD699 not found
gpg: public key of ultimately trusted key 5F2FA2F6 not found
gpg: public key of ultimately trusted key 5B81A1FD not found
gpg: marginals needed: 3 completes needed: 1 trust model: PGP
gpg: depth: 0 valid: 5 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 5u
pub rsa2048/81F88C88 2016-04-05 [S]

Key fingerprint = 5FB9 D2A5 255C 94E3 D06B  5B56 3C81 67E4 81F8 8C88

uid [ultimate] Otto Normalverbraucher <otto@example.invalid>
sub rsa2048/3E5BDFAF 2016-04-05 []

Fixed in 9354293.

gpg-agent does disable core dumps both in the stable and modern version.
Furthermore I have to agree with Werner here, if there is a process that can
ptrace your gpg-agent, then you have already lost anyway.

Fixed in abb352d.

Ok, if you agree that this is a useful feature then I will implement it.

Adding an API to the --quick-* commands of gpg 2.1 is no my shortlist for GPGME.
This will make things much easier - including key signing.

I can understand the reason to avoid binary data in a repo.

I have not checked but iff we use estream to access a plain old keyring it would
be possible to use the existing unarmor code and feed that to an es_fopenmem
object.

No, FLTK is not lightweight. It actually adds the requirement for a C++
compiler to GnuPG. And pinentry-w32 shall of course not die!

It is not trivial, but I guess we could create a temporary keyring and import
the key. But to be honest I don't understand why storing base64-encoded random
junk is somehow better than storing the junk itself, I mean it wont diff better
or something.

Just did it.

In sexp.c we use suitable_encoding to decide on how to print the value: Either
as token, as an escaped string or as a hex-string. This is only done when using
FMT_ADVANCED. We could come up with some heuristics on how to print in base64
instead of hex (i.e. |YWJj| instead of #616263#) but that has the drawback that
the output would not be readable by older versions of libgcrypt.

Hwoever, what can be done is to make do_vsexp_sscan work with base64 encoding -
as of now such a value is simply ignored.

Actually we are working on a 64 bit version.

Werner what is your opinion on this?

pinentry-w32 is broken. It does not handle variable string sizes and there is no
easy way to fix that. Afaik it was never intended as the "default" windows
pinentry but only as a crutch for windows ce experiments.

Would fltk be lightweight enough for your to replace pinentry-w32 in your
installer? In that case I think we should take a serious look at this patch as a
minimal pinentry version for windows.

(And delete pinentry-w32 instead)

I think in my previous messages the most important feature I'm missing was not
clear as I've mostly talked about subkeys and ECC curves. But what really
hinders me in making Kleopatra's key gen dialog more user friendly immediately,
even with default parameters for the key, is the API limit of only one user ID.

Meanwhile I also commited the Fedora patch.

Leaving the GUI vs. Commandline argument aside. I still think the batch keygen
API needs to be "modernized"

E.g. with improved authentication support in gnupg 2.1 it will become more
common to generate a key with an authentication subkey. Even the common case of
different Certify / Sign / Encrypt subkeys is not supported by the current API.

Maybe the Curves / Algos can be split up but I think gpgme needs API to query
supported Curves / Algos from GnuPG as this is more dynamic in GnuPG 2.1 then it
has been in previous versions.

Great! Thank you, Werner.