I don't mind a workaround that avoids an ABI/API fix as long as it defers actual failures until 2038.

I'm reopening this because i think users of these 32-bit platforms are going to run into issues before 2038 happens. Certs could appear expired before they are actually expired, for example, because of the wraparound time.

thanks for looking at this, @aheinecke ! if you or @werner know of any internal side effects where this does matter, it would be great to add a test that documents them.

(if you don't want to publish the full strace output here because you're concerned it might leak some information about your machine or your network, but you're ok sharing it with me personally, you can send it to me privately by e-mail, encrypted to the OpenPGP certificate with fingerprint C4BC2DDB38CCE96485EBE9C2F20691179038E5C6, and sent to one of the e-mail addresses associated with that certificate. please make a note here if you do that)

ok, that's deeply weird. i'm assuming that this machine has IPv4 connectivity. I have no idea why dirmngr would be returning EAFNOSUPPORT in that case.

branch dkg/fix-4821 contains a fix for this, in commit 414938cfedbdb97b83d00e8619dec9502096be22

in particular, c4cf527ea227edb468a84bf9b8ce996807bd6992 and f2aeb2563ba2f55eea7f52041e52062fdc839a64

The dkg/fix-4820 branch now has these two fixes.

For easier reference or searchability, the test error looks like this:

This appears to be a different error than above. here we see:

this looks to me like a problem with the TLS handshake -- it looks like this is a response coming from the TLS stack -- as rfc 8446 says, alert 49 is access_denied:

This is also https://bugs.debian.org/346241

thanks for the fix, @aheinecke ! can you post screenshots of the changes? or do you have a nightly build i could test?

In T4809#131931, @werner wrote:

BTW, the qualitybar is not shown by default, only if you configure sme of the extra password checks. We may even remove it completely because it leads to wrong assumption on why a passphrase is required.

@Rycky_Tigg cases 1, 2, and 3 that you document here each show the behavior that i would expect from pinentry-gnome3, given the definition of its Assuan-based API and its use of gcr-prompter. (i'm assuming that in case 3 the user just waited longer than the allowed timeout)

pinentry-gnome uses gcr's gcr_prompt_set_password_new to prompt for a new password, and ignores the SETQUALITYBAR assuan command.

It has now been over 6 months since the patches were available to fix this problem and they have not been adopted upstream.

@werner, i don't understand your last remark. what "required computations" do you think the proposed patches are "moving" from the server to the client?

fwiw, ensuring that overflow for either field results in ULONG_MAX (rather than wrapping around) would go a long way toward this problem being something that we can reasonably put off for another 50 years.

The most plausible fix to the Y2K38 problem on 32-bit machines is to simply move to a 64-bit time_t at the same time as any other major system-wide ABI break. However, if that ABI break doesn't also change the size of long to more than 32 bits, GPGME will remain unfixed in spite of any architectural correction.

Very few OpenPGP data signatures have an expiration time either, fwiw. I have never actually seen one in the wild, and no one that i know uses --ask-sig-expire or --default-sig-expire (it shows up in the cupt test suite and the apt test suite, but doesn't appear to be actually used by anything).

pinentry-tty is pretty fragile, and designed to be handled in a particular way. I strongly recommend a different workflow if you're using gpg secret key operations in a regular process. either:

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.