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.
Jan 10 2019
Done for libgpg-error.
Topic branch of libgpg-error is not good to show changes (for other libraries).
So, I made D473: Introducing LDADD_FOR_TESTS_KLUDGE to enable 'make check' with LD_LIBRARY_PATH.
Appliying to libgpg-error.
Jan 8 2019
For other distros, it seems it's quite old issue: https://sourceware.org/ml/binutils/2012-05/msg00037.html
My patches on the topic branch: https://dev.gnupg.org/source/libgpg-error/history/gniibe%252Fdisable-new-dtags/
Jan 7 2019
My tentative conclusion: When (GNU) ld supports --disable-new-dtags, add it to LDADD in tests/Makefile.am.
Dec 20 2018
Reading this discussion: http://lists.gnu.org/archive/html/bug-libtool/2018-01/msg00014.html
It seems that it could be fixed if we care about the order of libraries.
And it's not the issue for libgpg-error, which doesn't require external libraries.
For binutils, in Stretch, Debian specific patch was introduced.
Then, upstream introduced --enable-new-dtags option for configure to build binutils.
Now, Debian uses --enable-new-dtags option (at build time).