Also applied to gpgme.

Since there is no problem with libgpg-error 1.43, I applied it to other libraries: npth, libassuan, libksba, and ntbtls.

These are great news. Thank you!

Pushed the change to libgpg-error and libgcrypt (1.9 and master).
Let us see if there are any problem(s) for that, I will apply it to other libraries when it will be found no problem.

Thank you for the information.
For the record, I put the link to the email submitted:
https://lists.gnu.org/archive/html/libtool-patches/2020-06/msg00001.html

Oh, you are right, it's not upstream. It's actually applied to Homebrew (https://brew.sh/) libtool formula which is where I originally got libtool.m4, see:

I see your point. I'd like to locate/identify where the change comes from.
I think that what you refer by "new libtool.m4" is actually macOS local change (I mean, not from libtool upstream, AFAIK).
Could you please point out the source of the change?

That would work, however we might hit this issue with a new macOS release. Would it make more sense to update to what the new libtool.m4 is doing? Linker flags are the same, it only changes the way they detect macOS versions:

That does indeed not look like something which could introduce a regression.

I misunderstood as if we need to update libtool from upstream.

macOS has low priority for us and I do not want to risk any regression.

About merging our local changes.

We have our own changes for ltmain.sh and libtool.m4.

And update from automake 1.16:

It's better to update the set of files from libtool:

build-aux/ltmain.sh
m4/libtool.m4
m4/ltoptions.m4
m4/ltsugar.m4
m4/ltversion.m4
m4/lt~obsolete.m4

Our libtool was 2.4.2 + Debian patches + our local changes.
Debian patches are:
https://salsa.debian.org/mckinstry/libtool/-/blob/debian/master/debian/patches/link_all_deplibs.patch
https://salsa.debian.org/mckinstry/libtool/-/blob/debian/master/debian/patches/netbsdelf.patch

Applied and pushed.

(sorry, about my former comment, I only now realized that you did just that already in your original patch)

Updated:

diff --git a/configure.ac b/configure.ac
index 53a343b..f496729 100644
--- a/configure.ac
+++ b/configure.ac
@@ -82,6 +82,7 @@ AC_PROG_AWK
 AC_CHECK_TOOL(AR, ar, :)
 AC_USE_SYSTEM_EXTENSIONS

I guess the strcasecmp (nl_langinfo (CODESET), "UTF-8") results in some overhead, so if we do that what about kicking in only if a truncation is really to happen.

Sorry, I was wrong. It seems that GNU C library has a feature to avoid bad truncation.

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.

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.

No, c99 was never required. Meanwhile we use a few c99 features but those are supported without any compiler option.

-std=c99 is probably the reason that the tests fail.

Please try with out supplied CFLAGS or change them from

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.

This fix reveals the problem of: T4994: Windows: assuan_sock_init or WSAStartup by main/_init_common_subsystem

With the fix of T4623, this bug is now fixed.

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.

Thanks.
Merged (with line break in the Makefile.am and formatting of commit message.

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.

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.

gpg4win 3.1.6 is released which contains this fix.

Released 2.5.3 today:

Applied.

Done for gpgme.

Done for libgcrypt.

I give this normal priority to move it out of the "Needs Triage" queue.

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.

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/

My tentative conclusion: When (GNU) ld supports --disable-new-dtags, add it to LDADD in tests/Makefile.am.

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).

Marking this as resolved as it was forgotten in the testing state.

New gpg-error.m4 detects gpgrt-config, too.
And configure supplies --libdir when it invokes gpgrt-config.
For other *.m4 (libassuan, ksba, libgcrypt, ntbtls), it is possible for them to check GPGRT_CONFIG to use gpgrt-config if any.
For npth.m4, it can do that too, with no hard dependency to libgpg-error.