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).
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Nov 30 2021
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
Nov 23 2021
Nov 15 2021
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.
Nov 10 2021
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.
Nov 3 2021
Oct 29 2021
Oct 27 2021
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.
Oct 25 2021
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
Oct 19 2021
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.
Oct 17 2021
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.
Oct 13 2021
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.
Oct 8 2021
Oct 4 2021
Currently, I am using --lock-never config to avoid generating lock file as a workaround.
Oct 3 2021
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.
Sep 27 2021
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
Sep 22 2021
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?
Sep 21 2021
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.
Sep 2 2021
Sep 1 2021
Aug 30 2021
Aug 25 2021
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.
Aug 13 2021
Jul 28 2021
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.
Jul 27 2021
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!
Jul 26 2021
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.
Jul 24 2021
Using GPGME is probably the best way, even if gpgme-json might also work for some operations.
Jun 24 2021
Jun 7 2021
In your log, it says:
usb_claim_interface failed: -3
Sorry, I was wrong.
Jun 4 2021
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 verboseAnd share the debug output.
Ah, I think that your problem was fixed in rG53bdc6288f9b: scd: Recover the partial match for PORTSTR for PC/SC. (to be 2.3.2).
I see your situation
In T5442#146869, @gniibe wrote:If possible, please let us know how you configure the permission to access CCID device with 2.2 (and with 2.3)?
If possible, please let us know how you configure the permission to access CCID device with 2.2 (and with 2.3)?
Jun 3 2021
In T5415#146808, @KasparEtter wrote:Please excuse my late reply. I was busy with other things over the last few weeks.
Yes, putting disable-ccid into ~/.gnupg/scdaemon.conf works for me with GnuPG 2.3.1 under macOS Catalina (10.15).
I still don't understand what the problem is/was, so I cannot judge whether it's better to recommend this manual configuration for Mac users or to disable CCID by default on macOS.
Please excuse my late reply. I was busy with other things over the last few weeks.
Jun 2 2021
jitterentropy is also used in Linux kernel, and some people use clang to build it these days. So, I checked the kernel's one. It is simply compiled -O0 by Makefile, and there's no pragma line now (as of v5.13).
Jun 1 2021
I don't think that it is a good idea to silence this warning. The pragma is esssential for proper random numbers and if clang hijacks a GCC's name space but implements something different it is better to have a warning than to fall into the pit full of dragons.
So, has this issue been solved?
In T5369#144864, @jukivili wrote:That warning could be silenced by surrounding pragma with #ifdef __OPTIMIZE__ (with should be supported by GCC and Clang).
May 28 2021
Thanks. I push the fix of yours.
May 27 2021
Done for all (libgcrypt (master, 1.9, and 1.8), libassuan, ntbtls, libksba, gpgme, gnupg (2.2 and 2.3).
May 26 2021
May 25 2021
@werner @ikloecker Any more thoughts / updates on this?
May 21 2021
Thank you for your report.
May 19 2021
Please read also the report T5442 which is basically the same.
Thanks for the well written report. We had another already, and thus I merged it into T5415.
May 18 2021
May 17 2021
In T5436#146148, @ikloecker wrote:It's not clear whether you are talking about PIN caching related to signing operations or decryption operations.
Just got around to testing this on Linux, and I can confirm the same behavior: decryption PIN caching works on 2.2 and doesn't work on 2.3.
@znull You can also fix the detection issue by building with ./configure --disable-ccid-driver, in which case you won't need the disable-ccid setting anymore.
@ikloecker Sorry for not being clear, I was not aware different operations have different behaviors in regard to entering / caching the PIN.
It's not clear whether you are talking about PIN caching related to signing operations or decryption operations.
May 15 2021
I just wanted to chime in that I've had exactly the same experience as @lbogdan: gnupg 2.3 stopped recognizing my yubikey entirely on MacOS until the T5415 workaround (disable-ccid). After that, pin caching was broken until I applied his patch to call-scd.c:548, which makes it work as before. Without these two changes the experience with gnupg 2.3 is degraded relative to 2.2.
May 14 2021
So I did a bit more reading on smartcard PIN caching, and took a better look at the debug logging of gnupg 2.2, and learned that, indeed, the PIN is cached by the card and not by any one gnupg component.
May 12 2021
Yes, I already linked to T5415, but that breaks YubiKey completely, and I fixed it with disable-ccid.