Fixed in libgcrypt 1.10.2.

Tested. I applied the above diff to libgcrypt-1.10.2, and it builds and runs.

Thank you for the report.

Here is the git diff that I used:

I just ran into this, too, on macOS.

You could configure gpgme with

Good catch. The translation of the option descriptions is done as part of the option parser (libgpg-error/src/argparse.c) and thus we need to have gettext support over there. Also for some other error messages.

Seems to work if NLS support is enabled. Updating in https://github.com/Homebrew/homebrew-core/pull/122706. Once merged, users will need to brew reinstall libgpg-error (Homebrew has decided to avoid forcing updates to all users outside of critical fixes).

Probably due to libgpg-error being built without NLS support on macOS as formula currently doesn't have gettext dependency. On Linux, libintl is provided by glibc so doesn't need any extra dependencies.

This is the formula: https://github.com/Homebrew/homebrew-core/blob/c26f1c8714c231ee6796915f033ba229c89af3d6/Formula/gnupg.rb

I have no idea about Homebrew - can you figure out the maintainer and point him to here?

I just moved Phabricator to a new machine and created separte certificates for files.gnupg.net and dev.gnupg.org.

Thank you. I am glad that it is already resolved.

Will this be in the next release of libgcrypt?

Okay. So, I removed gpg-error-config, updated libgcrypt/m4/gpg-error.m4, and then rebuilt configure. And, gcrypt configures and builds.

Thank you for the information.

Actually, it looks as if libgpg-error-1.46 already has that fix.

Thank you for your quick reply.

Yes, it is on macOS.

From the information in gpg-error.pc, I think it's on macOS.

A better solution could always be found later

Sorry.

We provide lots of different flavors of pinentry, but we do not provide pinentry-mac. You'll have to talk to the people you got pinentry-mac from.

What would be setting those? And how do I disable it?

It does have them defined!

$ gpg-connect-agent "getinfo getenv COLUMNS" /bye
D 80
OK
$ gpg-connect-agent "getinfo getenv LINES" /bye
D 24
OK

What would be setting those? And how do I disable it?

A possibility is that gpg-agent which invokes pinentry happens have COLUMNS and LINES defined, then, pinentry misbehaves.

Thanks again for further information.

Hmm, I added that to my formula, and see ncurses 6.3 now, however the issue still occurs.

dyld[20991]: <55AFFB3D-2011-35CC-9486-B30BC1CA12F7> /opt/homebrew/Cellar/pinentry/1.2.0/bin/pinentry-curses
dyld[20991]: <AAD35EC9-FC8A-3ED4-A829-C59E710CEA8A> /opt/homebrew/Cellar/libassuan/2.5.5/lib/libassuan.0.dylib
dyld[20991]: <59683137-0511-3681-8BA6-04A78592B197> /opt/homebrew/Cellar/libgpg-error/1.43/lib/libgpg-error.0.dylib
dyld[20991]: <A9DA1A80-D101-339B-9637-85A65285E050> /opt/homebrew/Cellar/ncurses/6.3/lib/libncursesw.6.dylib
dyld[20991]: <679CDB15-D472-38E8-8840-B38874010D51> /usr/lib/libSystem.B.dylib
dyld[20991]: <BB47A721-69A7-3EEA-9D9B-82F88FFF2641> /usr/lib/system/libcache.dylib
dyld[20991]: <E6CCD148-5E91-3111-BE37-1C19402F4637> /usr/lib/system/libcommonCrypto.dylib
dyld[20991]: <92001FF7-799E-3BA8-BF46-5FA01FFB952C> /usr/lib/system/libcompiler_rt.dylib
dyld[20991]: <6BE94DC2-F363-3D76-B056-F45D4B56E152> /usr/lib/system/libcopyfile.dylib
dyld[20991]: <881973B2-0426-325F-8D1A-17D60AE0CBFA> /usr/lib/system/libcorecrypto.dylib
dyld[20991]: <9C4116F5-B8EB-3A00-B4B5-54AF6A76F66B> /usr/lib/system/libdispatch.dylib
dyld[20991]: <96ECED73-F10C-3941-91A7-00254B907499> /usr/lib/system/libdyld.dylib
dyld[20991]: <F7CDC52B-7961-3283-A30F-B06E2E6ED6AB> /usr/lib/system/libkeymgr.dylib
dyld[20991]: <8D2BECEF-1038-3F2C-B8EF-B02C03092286> /usr/lib/system/libmacho.dylib
dyld[20991]: <3D861651-91A7-3D78-B43B-ECAA41D63D9E> /usr/lib/system/libquarantine.dylib
dyld[20991]: <FA2D8F89-D9C4-316F-9FDC-BFF1A791BD4E> /usr/lib/system/libremovefile.dylib
dyld[20991]: <61963381-E322-3D0F-855D-CE1EA31FA4E1> /usr/lib/system/libsystem_asl.dylib
dyld[20991]: <770FEB1F-FE27-3670-810F-A063D281CC8D> /usr/lib/system/libsystem_blocks.dylib
dyld[20991]: <660D7866-E2A2-3651-A0A5-806E9217736B> /usr/lib/system/libsystem_c.dylib
dyld[20991]: <1F580793-A1C3-30C6-A9BC-7789C14677AE> /usr/lib/system/libsystem_collections.dylib
dyld[20991]: <8370E8A5-EADF-3A2C-9D5B-CA148723A5CA> /usr/lib/system/libsystem_configuration.dylib
dyld[20991]: <30C492F6-C9E6-3C1D-BE52-CA4F4FC824D6> /usr/lib/system/libsystem_containermanager.dylib
dyld[20991]: <F2A34B01-C264-3B7E-B3C9-1671E9E3C185> /usr/lib/system/libsystem_coreservices.dylib
dyld[20991]: <01C0D793-E5FB-3141-95D6-32A973F9FFF8> /usr/lib/system/libsystem_darwin.dylib
dyld[20991]: <AED9DAFC-7AB1-31CF-96A1-14C87B614DD3> /usr/lib/system/libsystem_dnssd.dylib
dyld[20991]: <F0456F65-B4DF-3E14-91DC-C0C2A7954233> /usr/lib/system/libsystem_featureflags.dylib
dyld[20991]: <5E36F087-5EF7-33B7-ACDA-CAE1C4A97621> /usr/lib/system/libsystem_info.dylib
dyld[20991]: <6AB180A4-1D1E-3FA1-88B7-A7866EFACFC8> /usr/lib/system/libsystem_m.dylib
dyld[20991]: <7C9F7726-62C1-3B03-8130-03E8A2A68DDF> /usr/lib/system/libsystem_malloc.dylib
dyld[20991]: <2F331637-80F6-3208-816F-618DA9081899> /usr/lib/system/libsystem_networkextension.dylib
dyld[20991]: <3701D756-7023-30C0-9A36-852971092AA9> /usr/lib/system/libsystem_notify.dylib
dyld[20991]: <4234FAEC-7D18-30E7-AEAD-E9FB6922AFE9> /usr/lib/system/libsystem_product_info_filter.dylib
dyld[20991]: <1214F568-24BF-379F-8A86-FF947EE5F18A> /usr/lib/system/libsystem_sandbox.dylib
dyld[20991]: <49553CC1-66C3-32B1-91C6-4415DE230F58> /usr/lib/system/libsystem_secinit.dylib
dyld[20991]: <17550B77-D255-389A-B779-906AF75314B6> /usr/lib/system/libsystem_kernel.dylib
dyld[20991]: <8B28F7A3-6681-3D34-92AE-3688A74F50E6> /usr/lib/system/libsystem_platform.dylib
dyld[20991]: <AA39FF66-B3F0-3777-99BC-F4A4C5CBD566> /usr/lib/system/libsystem_pthread.dylib
dyld[20991]: <73885FA5-76B6-3AA3-8D91-60B2E0078F99> /usr/lib/system/libsystem_symptoms.dylib
dyld[20991]: <362E885B-20EA-395B-BB01-6E46B864294D> /usr/lib/system/libsystem_trace.dylib
dyld[20991]: <D0A538E3-7A75-395A-993C-A3EA7947F55A> /usr/lib/system/libunwind.dylib
dyld[20991]: <A77B4CE2-0855-3C19-B4A6-47B094CF0DDA> /usr/lib/system/libxpc.dylib
dyld[20991]: <52A50407-CD9B-3A67-A0C2-2D9D6F3043BF> /usr/lib/libc++abi.dylib
dyld[20991]: <8FCA2160-F786-398A-AEAC-2B3D5BD72BB8> /usr/lib/libobjc.A.dylib
dyld[20991]: <6B0DE0DE-0EA2-3948-8B7D-8BA309414B27> /usr/lib/liboah.dylib
dyld[20991]: <20FBE382-CC21-324E-8813-C84B94CC04EF> /usr/lib/libc++.1.dylib
dyld[20991]: <A714AC09-9E2D-3608-B8C1-D6300E852308> /usr/lib/libiconv.2.dylib
dyld[20991]: <1907D41B-6D4B-3EA0-AD3B-5770431B6327> /usr/lib/libcharset.1.dylib

So, the solution is to build pinentry with newer ncurses. As I wrote in another comment, it's adding a single line to the formula.

Thank you for the info.

I ran DYLD_PRINT_LIBRARIES=1 DYLD_PRINT_LIBRARIES_POST_LAUNCH=1 DYLD_PRINT_RPATHS=1 pinentry-curses and see libncurses.5.4 (full output below).

Is there some other command I should run to check which curses it's using? I see there's a --debug flag but I'm not sure how to use it.

I think that either of following might be true:
(1) macOS has older ncurses (which doesn't support ioctl well, to get columns/lines info) in system
(2) macOS has BSD curses (with no suport for ioctl)

I installed it with brew and didn't provide any special options. This is one of the new M1 macs though, so perhaps there is some platform check deep in the install that is getting confused?

Thank you for the information. So, you don't have these environment variables set.

printenv COLUMNS LINES shows no output, however if I echo $COLUMNS $LINES I see 160 48 both before and after the password prompt.

Curses application (of pinentry) get information of screen size by:

• environment variables (COLUMNS, LINES)
• operating system using TIOCGSIZE or TIOCGWINSZ ioctl
• tinfo data base

Also, and I should maybe have opened with it, the issues vcpkg has with your build system are currently tracked here, while my effort to build gpg-error natively (i.e. without relying on ShiftMediaProject fork) on all platforms is here.

In T5365#151844, @gniibe wrote:

Let me clarify the use case of gpg-error.m4.

gpg-error.m4 is for GnuPG and its friends, where we cannot assume availability of pkg-config. Its capability is limited, and we don't pursue 100% compatibility of pkg-config.

Let me clarify the use case of gpg-error.m4.

In T5365#144688, @gniibe wrote:

If it is new, it may be the change of this commit rC8e3cd4c4677c: build: Update gpg-error.m4.

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.

I think we can close this bug. The warning will now only be printed as part of the the regression test and after all it is just a warning.

It seems like this warning does break some usages of gnupg on macOS.
We found one when packaging this in Homebrew: https://github.com/tadfisher/pass-otp/issues/147

Thanks for the clarification. So it's just a matter of not emitting the warning I guess?

gnupg_bindir() uses unix_rootdir() falling back to the builtin configure time path if unix_rootdir() returns NULL. So, there is no difference.

I second this. This is problematic on (Free)BSD too, where /proc is usually optional and might not be mounted at all. I concur that this should be silenced if not running in debug mode.

Urgs, I already implemented this:

On macOS _NSGetExecutablePath could be used, but iiuc this requires linking against dyld. For other OSes we would also need more code. I doubt that this makes a lot of sense these days; but we should come up with a solution, even if that means we need an envvar to specify the location of that open gpgconf.ctl file.

No, the error is harmless. I guess it shouldn't be printed (except when debugging).

We now require a way to get the actual image of a process. For macOS the BSD method is used and we obviously need to find another way for macOS.

Currently, I am using --lock-never config to avoid generating lock file as a workaround.

Sorry, a hostname with slash is simply not allowed by IETF standards. Given that the hostname is part of temporary file names, you will run into an error. Yes, we could remap the slash in the mktemp function but there are lot of other plzces where the hostname is used and certain properties are expected.

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.

Closing, as downstream ticket has been closed.

Fixed in libgcrypt 1.9.4.

It must be fixed in 2.3.2. If not, please report.

dlopen'ing of gpgme is NOT SUPPORTED. It is in general not a good idea to do this on standard Unix systems.

To extend on this: dlopen'ing of gpgme is NOT SUPPORTED. It is in general not a good idea to do this on standard Unix systems. On Windows we could make it work because DLLs on that platform are well designed and not a hack like the Unix shared objects.

We really want thunderbird users that interact with GPGME to have a great and stable user experience, but the problem with dynamic loading and self compiled versions is that we cannot really know the build settings and enviornment and it is very time consuming to reproduce that. GPGME does some very low level things for optimized IPC that can depend on build options etc. This is why I am mostly in favor that thunderbird ships a defined version that we can debug and see the settings.

Reading the mozilla entry more carefully, there still seems to be an issue.

https://blog.gerv.net/2012/01/mozilla-projects-and-gpled-code/

@kaie, thanks for the pointer!

In T5250#148131, @bernhard wrote:

BTW @kaie

Thunderbird cannot use anything requiring GPL in its default configuration, because Thunderbird wants to distribute a single MPL licensed package that includes all components that are required for OpenPGP.

Any pointer why, they have made that choice, though? A bundle of MPL and GNU GPL components is fully allowed by the licenses as far as I know.

Using GPGME is probably the best way, even if gpgme-json might also work for some operations.

In your log, it says:

usb_claim_interface failed: -3

Sorry, I was wrong.

I need to see how we can pass the check permission notice up to gpg. This is a too common problem and thus serves some special treatment.

GPG Version :

In T5442#146871, @gniibe wrote:

I see your situation

Could you please help me to analyze what's going on?
Please add following lines to your scdaemon.conf to see CCID driver's debug output:

debug-ccid-driver
verbose
verbose
verbose

And share the debug output.