Perhaps, it's better to remove -no-install flag in tests/Makefile.am, so that test programs will be wrapper script by libtool.

Asked to raise the priority on this. The quality bar issue is T2103

It seems it's Ubuntu specific: https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1796563

Last week:

• GnuPG 2.2.12 released
• Meeting with RK for the Verein

I had to look it up in the code and man page too ;-)

See T4293

With GCRYCTL_AUTO_EXPAND_SECMEM we won't anymore run out of secure memory. This has even silent been backported to 1.8.x (using the numerical value of that constant) and is for long an option of gpg-agent. Thus closing.

Closing, given that we implemented a general solution; see the parent task.

I have seen no responses on your two mails to the ML and given th athere is no concrete protocol bug, I close this issue. If you can show a concrete bug please re-open this issue again.

I don't think that this is a good solution for a problem we could solve much easier but fear to do that due to kind of crypto politics.

Good to know. I thought that ocsp-signer was only used if ocsp-responder is explitly set. I've suggested the workaround in the Message Board.

Is using

I think that all that we can do is to improve documentation.

Apparently, it's an error from your installed /usr/local/opt/libgpg-error/lib/libgpg-error.0.dylib (you have some configuration to prefer this library), while your configure is for /usr/local/lib (because you specify no --prefix).

Please let us know the version of GnuPG, the output of gpg --card-status when inserted, and how gpg is not working well, etc.

How scdaemon responds when there is no card available?

that error means that the message was somehow corrupted during transfer. Are you maybe using ftp in text mode on a binary message for example?
You could ask your communication partner to send you messages in text (ASCII Armor) mode which is more robust.
In Kleopatra you can change that in Settings -> Configure Kleopatra -> Crypto Operations -> Create signed or encrypted files as text files.
On the command line you need to add "--armor" option.

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.

Even with the logging changes this still happens. I just retested it. Can't run Kleopatra on Linux with GPGME_DEBUG=9.

Last week:

• Finished FST-01SZ design (tagged release/3.0.1), confirmed production
• A bug fix in master for decryption checking smartcard keys: rGebf775eb16fe: card: Suppress error message by agent_scd_cardlist.
• Re-evaluate T4281: Backport smartcard support changes to 2.2
• My problem for ack button found hardware issue: unstable USB connection results USB Reset

In FreeBSD, getrandom(3) became available, when getrandom(2) was added. <-- This is my theory.
If this is true, just use getrandom(3), not using getrandom(2) by syscall.

It became common, because many people now use larger keys.
For RSA-4096, three simultaneous connections for decryption may cause the failure.
In the experimental patch of D472: Limit active connections for gpg-agent, I limit two connections.

increment the counter is better done by the looping main thread.

This is an experimental patch. So, I just reuse SIGUSR1 to wake up "select"-ing thread by kill(2).
I put limit-active-connections 2 in gpg-agent.conf for the test with run-threaded of gpgme.

Agreed this looks like it should be made default behavior. This has affected many people I work with, and even with searching, this ticket never came up. I only found out about it by making a ticket myself. This issue looks like it has generated at least 3 tickets in this bug tracker, and the agent is raising memory errors during normal usage, which still smells like a bug to me.

Though not directly related to our issues, this bug report on the MSYS2 site reported by their users encountering trouble with GPGME provides additional weight to irreconcilable differences between MSYS2 and GnuPG:

So if your DNS resolver does not tell us the IP addresses, we can't do anything about it.

The usual reasons for corruptions of binary data are FTP transfers in text mode; or opening a file with a Windows editor.

NEWS are:

Got another reliable report in the Wald Forum about this. https://wald.intevation.org/forum/message.php?msg_id=6371&group_id=11

No I do not think so. Because that would already be currently the case. If you had a subverted Root CA of course you can attack. But we are only talking about CRL / OCSP here. A root CA that does not provide a CRL for certificate X is OK. As long as the Root CA that issued X issues a CRL for that. Well the usual CRL / OCSP denial of service is still possible but I don't see any subversion.

Interesting idea but it does not help against attacks because all root CA are considered equal (virtually cross-signed). Thus a single not checked root CA allows to subvert all certificates.

I wonder if the best thing here might be another flag in the trustlist to disable CRL/OCSP checks for a single root certificate chain. I had such a request in the Gpg4win forums. Someone had a single unreacable CRL / OCSP and had to disable globally all checks for all other certs, too.

yes. that's why i wrote it in '['-brackets.
but usually, in info-documents a synopsis is written about it.
I think that it's not self-evident, that "you can either give a file or let the tool read from stdin or output to stdout" and therefore should be written explicitly.

Adding the patch here.