Mon, Mar 22
Jan 2 2021
Hi there, this change is very useful on the Homebrew project's upcoming ARM port. The Mac package manager's base library prefix will change from the existing presumed defaults to prevent backwards-incompatibility, making pkg-config compatibility somewhat more important.
Nov 16 2020
Oct 23 2020
Sep 3 2020
To implement this it would be best to have an gpg_strerror variant which does not call dgettext.
re 1: Correct utf-8 truncation would be quite some work. In this case the message is in the Assuan interface is a debugging aid. Translation is not necessary so we can try to disable it.
Aug 17 2020
No, c99 was never required. Meanwhile we use a few c99 features but those are supported without any compiler option.
Aug 14 2020
-std=c99 is probably the reason that the tests fail.
Please try with out supplied CFLAGS or change them from
Jul 29 2020
We have had this in the past but it led to subtle build and, worse, runtime problems. Thus the decision to provide architecture dependent files and have configure complain for wrong files. Right, you sometimes get false warnings for non-matching cpu-vendor-os strings but I consider this less severe than the old problem.
Jul 16 2020
This fix reveals the problem of: T4994: Windows: assuan_sock_init or WSAStartup by main/_init_common_subsystem
Mar 12 2020
Feb 18 2020
With the fix of T4623, this bug is now fixed.
Dec 6 2019
Aug 20 2019
Well, gpg-error is special. For other libraries, adding -I and -L is enough and good.
Fixed in master.
Thank you. I only tested a configuration where installation of libassuan has same prefix as libgpg-error. That's the reason why this bug exists.
Aug 19 2019
Jul 18 2019
Merged (with line break in the Makefile.am and formatting of commit message.
Jul 17 2019
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.
Jul 15 2019
Jul 1 2019
As I said we do this with all GnuPG components. Pinentry is a bit of exception because it is an external package.
I have also had bug reports which later turned out that a wrong pinentry was used; I prefer to know eactly which pinentry is used. Regarding your concrete problem I suggested to add a note with the full name of the pinentry or to change the error message to something better understandable.
So this is a defense against an adversary capable of creating a pinentry-wrapper somewhere in $PATH, but not capable of modifying gpg-agent.conf? It sounds to me like this is a defense against a very unusually-constrained attacker, at the expense of regular, common bug reports and user confusion.
GnuPG invokes its components always with their absolute file name. We want to mitigate attacks where malware creates a pinentry wrapper somewhere in an improper set PATH.
Jun 27 2019
Mar 27 2019
gpg4win 3.1.6 is released which contains this fix.
Feb 25 2019
Feb 19 2019
Feb 11 2019
Released 2.5.3 today:
Jan 17 2019
Jan 16 2019
Done for gpgme.
Jan 15 2019
Done for libgcrypt.
Jan 14 2019
I give this normal priority to move it out of the "Needs Triage" queue.