I think this patch should be backported to STABLE-BRANCH-2-2

I think this patch should be backported to STABLE-BRANCH-2-2

I can confirm that this fix repairs the problem on debian's s390x.

I've just pushed e4a158faacd67e15e87183fb48e8bd0cc70f90a8 to branch dkg/fix-T4501 as a proposed fix for this specific problem (it doesn't introduce anything in the test suite, or try to deal with any of the other %b problems).

OK, i think the reason this is happening is that agent_public_key_from_file (in agent/findkey.c) is screwing up a %b format string in gcry_sexp_build_array.

Ok, the difference appears to be that on these 64-bit big-endian platforms, they're returning a zero-byte string for the associated comment. When this happens, gcry_sexp_canon_len returns 0 because of GPG_ERR_SEXP_ZERO_PREFIX. The same thing happens on x86_64 platforms when confronted with such an s-expression.

It looks to me like gcry_sexp_canon_len is returning 0 on these platforms from within a backtrace like this:

I've just pushed 29adca88f5f6425f5311c27bb839718a4956ec3a to the dkg/fix-T4490 branch, which i believe fixes this issue.

And, i just discovered that when i manually edit the key to remove the (comment) list from the *.key S-expression file, the final --export-secret-key works fine. so the failure appears to be due to the presence of the (comment) clause. (same as in T4501)

And, i just discovered that when i manually edit the key to remove the (comment) list from the *.key S-expression file, everything works fine on s390x. so the failure appears to be due to the (comment), just like in T4490.

fwiw, i've just tried loading the same keyfile that the s390x (64-bit big-endian) implementation choked on into a running gpg-agent on an amd64 machine (64-bit little-endian) and gpg --full-generate-key succeeded with that same key on amd64.

I keep this open to track the mentioned change for gnupg 2.2

I also did a base64 < "$GNUPGHOME/private-keys-v1.d/".key at the end of a different run of that script, and it produced this output, if you'd like to inspect the actual S-expression stored:

I ran the example script from T4490 on an s390x machine, and got the following output:

This might be related to T4490, since it's the same sort of key generation process.

I was trying to use the above technique to be able to generate an OpenPGP transferable secret key in an ephemeral homedir. Ephemeral directories are recommended in the GnuPG info page's "unattended usage" section, but they do not work here.

Good that it works again for you.

This was most likely a (chipcard) hardware issue. It went away after polishing the contact pads for a bit. Possibly my laptop reader applies more force...

I forgot: Instead of importing the missing internal CA, this works:

I agree, the question is which CRL is checked when how. Maybe there is some mistake on my side. Here is a recipe for Debian:

I don't think this is a bug. Failure to encrypt when CRL check fails is expected.

I applied https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=patch;h=8d1b5982138c104f3c50663738892fa110193059 on top of 2.2.14.

We fixed that in master and 2.2. Can you please test this with the next release and report or close this bug?

Thanks for the report. underscore followed by an uppercase letter is actually reserved for the system; thus we should not have used that.

Also might I add, this used to work perfectly fine in gnupg14. It seems that somewhere along the line a regression was introduced that is causing this erroneous non-compliant behavior in the HTTP client.

Why? Your explanation is invalid because it implicates dirmngr's HTTP client as not comforming to the spec laid out by the RFC. I've quite clearly explained--and backed up with the spec itself--that when a proxy variable is configured, a client should not be doing DNS lookup of the destination hostname. Is there something about that you are not understanding?

News for 2.2.14, released 2019-03-19:

Please show an example regarding something else than a failed access to a pool of keyservers. I explained why it can't work for pools for you.

Yes you can, and no you do not. Don't believe me? Then read the spec. At no point does the spec say that there is "nothing that can be done" when a hostname cannot be resolved when connecting through a proxy. In fact, it states precisely the opposite, describing the exact procedure a client should take when making a request through a proxy. See section 5.3, paragraph 3:

We can't replicate that and got no more response for 9 months.

TPK ?
TPS ?

In T4393#123047, @dkg wrote:

i don't understand why "import-drop-uids" is useful --

i don't understand why "import-drop-uids" is useful -- it sounds to me like the functionality you're looking for is something more accurately named "accept-certs-without-uids". is that right?

This is caused by the encoding of file in windows. If we directly redirect the stdout to file, windows encodes the file as CRLF+UCSE LE BOM but linux encodes it as LF+UTF-8. To make the file work, I just need to run dos2unix to convert the encoding. Hope it help someone having similar issue.

Your problem is apparently not an issue of upstream development of GnuPG; It is your setup script (agent.sh?) which specifies /dev/shm/SOMETHING.
Standard GnuPG never does that. We have no idea about use of /dev/shm/SOMETHING.

Thanks for the report. Fix will be in the next release.

In Wald someone reports that this also appears to happen when decrypting. https://wald.intevation.org/forum/message.php?msg_id=6377 Probably run-threaded will help to flush this out.

NEWS are:

If you specify a pool of keyservers dirmngr selects a keyserver on its won from the pool. This is so that it can use its own heuristics to detect whether a keyserver is dead and then retry another one. Now the default is a pool and your specified keyserver.ubuntu.com is also a pool (of two servers). So if your DNS resolver does not tell us the IP addresses, we can't do anything about it.

In your second run you added the options after the argument (4E2C6E8793298290) so they won't have an effect. Anyway, I can't see anything from the output. My way to debug that would be to run gpg under strace:

hm, adding: --with-tar=tar to my invocation of ./configure appears to leave gpg-zip with:

I have a warning already in my working copy.

i don't see any active use of it in all of debian: https://codesearch.debian.net/search?q=gpg-zip

Let me also note that gpg-zip was not installed since 2006 due a conflict with gpg1.

gpg-zip is deprecated because we have replaced it by gpgtar. Given that you have a workaround for Debian I tend to close this bug as WONTFIX.

I don't think this answered my question -- i'm asking how adding --no-keyring affects gpgme_op_decrypt_verify -- it seems like verification would fail if no keyring is used, no?

gpgme_op_decrypt_verify can always be used instead of gpgme_op_decrypt. This is an obvious requirement because the signature and the fact that there is a signature is only known after the decryption step. The newer GPGME_DECRYPT_VERIFY of the gpgme_op_decrypt_ext function is basically an alias for gpgme_op_decrypt_verify.
For both functions gpgme employs "gpg --decrypt".

I'm fine with this change, but i do note that some people expect --decrypt to mean "decrypt and verify, if possible". In particular, gpg(1) says about --decrypt:

Released: https://lists.gnupg.org/pipermail/gnupg-announce/2018q4/000432.html

• gpgsm: Fix CRL loading when intermediate certicates are not yet trusted.
• gpgsm: Fix an error message about the digest algo. [T4219]
• gpg: Fix a wrong warning due to new sign usage check introduced​ with 2.2.9. [T4014]
• gpg: Print the "data source" even for an unsuccessful keyserver query. ​
• gpg: Do not store the TOFU trust model in the trustdb. This allows to enable or disable a TOFU model without triggering a trustdb rebuild. [T4134]
• scd: Fix cases of "Bad PIN" after using "forcesig". [T4177]
• agent: Fix possible hang in the ssh handler. [T4221]
• dirmngr: Tack the unmodified mail address to a WKD request. See commit a2bd4a64e5b057f291a60a9499f881dd47745e2f for details.
• dirmngr: Tweak diagnostic about missing LDAP server file.
• dirmngr: In verbose mode print the OCSP responder id.
• dirmngr: Fix parsing of the LDAP port. [T4230]
• wks: Add option --directory/-C to the server. Always build the​ server on Unix systems.
• wks: Add option --with-colons to the client. Support sites which​ use the policy file instead of the submission-address file.
• Fix EBADF when gpg et al. are called by broken CGI scripts.
• Fix some minor memory leaks and bugs.