To be clear, i believe @mgorny means that he wants the User ID containing the e-mail address to be considered *valid* (that is, full or ultimate validity). I don't think this operation should care about ownertrust.

it's been almost a quarter year since my last nudge on this supplied patch. It's not clear to me why it hasn't been merged in master. I'm trying to not be a nag, but:

DETAILS says:

*** PLAINTEXT_LENGTH <length>
    This indicates the length of the plaintext that is about to be
    written.  Note that if the plaintext packet has partial length
    encoding it is not possible to know the length ahead of time.  In
    that case, this status tag does not appear.

@werner, are you saying that gpgme is not fully supported for use with gpg 1.4?

@werner, you seem to be saying that -r does not imply "key lookups on remote services". Is that correct?

There is a growing bit of popular lore in the GnuPG community that "when keyserver operations fail, you solve that problem with killall dirmngr." I believe this suggestion is potentially damaging (the long-running daemon may be in the middle of operations for a client that you don't know about), but i suspect it is circulating as advice because it resolves the situation outlined in this ticket. For whatever ephemeral reason, dirmngr gets stuck, and fails to notice that this situation has resolved itself.

@justus can you provide an example of the gpgme code you're using that generates this weirdness?

I agree with @werner that when presented with a User ID with self-sig with preference, the preferences subpackets from the self-sig should take precedence.

yep, the implementation thinks that the default signing key is expired due to metadata contained in the public keyring. The secret key is available to the implementation. So the error mesage No secret key can cause confusion and/or panic if the user thinks they've actually lost their secret key.

fwiw, i can reproduce this on debian unstable with gpg version 2.2.17, without a redirected agent -- so the agent redirection isn't relevant here.

@stm -- thank you for this!

i'm actually running make -j3 check, since make -j3 distcheck has the problems described in T4688.

So i've been able to (intermittently) reproduce the failures that i think @werner was alluding to here, but not under any circumstances where i can get them to happen reliably to understand what's going on.

It has now been more than a month since:

Thanks, @gniibe. From reading this patch (i haven't tested it), it looks like it would avoid most unnecessary agent launches (and agent communication) in the (b) case, which is a win over the status quo.

This was also raised for (hopefully) wider discussion on the IETF mailing list.

i've just pushed rGc4b9eba1d6a63b73238dcbb644b365dc53563f3d to the dkg-fix-T4682 branch resolve this.

@skeeto can you edit the summary/title of this ticket to better reflect what you think the underlying issue is?

This appears to be https://bugs.debian.org/850946 and it does not appear to be fixed to me.

reviewing this, i think the situation is:

Are you seeing mixed-up MIME parts? or a different problem?

WKD and DANE/OPENPGPKEY offer rather distinct properties. I'd be hard-pressed to say that one is "better" than the other without understanding the threat model and concerns of the evaluator:

I also observe that the text in the GUI prompts is remarkably unclear on its own. setting aside the grammar, punctuation, and wording, the prompts don't expose the usage flags set for the secret keys, which is possibly the only detail that a user with a single OpenPGP certificate would care about: "am i deleting my signing-capable subkey or my decryption-capable subkey?"

Please update the documentation for the function in that case.

Please see my explanation on gnupg-devel about why the trailing NUL is a source of pain and difficulty for would-be adopters.

I've just uploaded pinentry 1.1.0-3 to debian unstable with this fix in it.

@aheinecke thanks for the heads-up. i'll pull this in.

@aheinecke

Due to socket forwarding we can have different versions of gpg-agent and gpg / gpgsm because they are on different machines and afaik we try to support it.

fwiw, if the old gcrypt actually returned a radically different API, it should have a larger SONAME across that change, and NEED_LIBGCRYPT_VERSION should reflect a source version that forces it past that SONAME. I don't know what version of libgcrypt behaved differently -- is there a reference for that?

I don't think there's a problem to have a long explanatory message in the main repository, as i think it makes it easier to understand, and space is not an issue.

I've just broken out my changes into two commits, one that makes gpg and gpgsm more robust. That should be applicable without any risk.

I've just posted rGb84feb0c82eb to the dkg-fix-T4652 branch, which solves the failure problems by making agent_pkdecrypt and gpgsm_agent_pkdecrypt more robust.

fwiw, this patch appears to cause gpgsm to fail its test suite:

I've just pushed rG1ae16838660a to the dkg-fix-T4652 branch (i just adjusted it the commit message to include the GnuPG-bug-id)

This report doesn't contain enough information to be able to tell you why the command is failing within your program, but not failing outside of it.

@werner wrote:

Other tasks in master are right now more important.

I've just pushed rE732855a483709345a5c0f49504f45cb8da3f883a to dkg-fix-T4643 in the gpg-error git repository. I don't know why it is not yet visible here.

CC_FOR_BUILD is defined in configure.ac as build system C compiler, not build system C compiler and flags.

I'm aware of you releasing an RC for comments, and i apologize for not catching this particular case earlier. As you know from T4607, i was even advocating for it. i didn't understand the full implications of the "import-then-clean" approach at the time, and was thinking it would only apply to the incoming material, not the stored material.

i've merged a variant of rGbe99eec2b105eb5f8e3759147ae351dcc40560ad into the GnuPG packaging in debian unstable as of version 2.2.17-3 to avoid the risks of data loss and signature verification failures. I'll revert it if i see the concern addressed upstream.

@gniibe, thank you for backporting this to STABLE-BRANCH-2-2!

I don't know why dkg-fix-T4641 is not showing up here on the assuan git repo.

I've just pushed rA45f01593d4ce794ae3562359aee2ff80c97e368e to the dkg-fix-T4641 branch that resolves this.