Re: [OpenIndiana-discuss] GPG2 on OI
There is also a way to use the /usr/lib/pinentry-curses that is linked against the Sun libcurses. The program supports a -c option to set colors where you must provide a comma (,) separated list of curses colors. If you set colors like : /usr/lib/pinentry-curses -c "white,black,cyan" and of course gpgconf --kill all, to kill gpg-agent, then it displays fine (using curses, not ncurses). Anyway this looks like a really old bug ... the header file of pinentry-curses is (c) 2002 so this is probably already a longtime the behavior of pinentry-curses. It doesn't seem hard to fix if the GnuPG developers would download an OpenIndiana ISO, install it, and test it. David Stes - Op 4 okt 2021 om 5:50 schreef Discussion list for OpenIndiana openindiana-discuss@openindiana.org: > In regard to: Re: [OpenIndiana-discuss] GPG2 on OI, Andreas Wacknitz said...: > >> Today I have updated pinentry to the latest 1.2.0 version and also switched >> from curses to ncurses. >> My hope is that this will solve many reported problems. > > Hmmm, I did say I was working with the gnupg developers on that issue too, > and I mentioned on the oi-devel list I was going to update pinentry, but > if you prefer this approach, that's fine. > > I will close the ticket I opened against pinentry. > > Tim > -- > Tim Mooney tim.moo...@ndsu.edu > Enterprise Computing & Infrastructure / > Division of Information Technology/701-231-1076 (Voice) > North Dakota State University, Fargo, ND 58105-5164 > > ___ > openindiana-discuss mailing list > openindiana-discuss@openindiana.org > https://openindiana.org/mailman/listinfo/openindiana-discuss ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] GPG2 on OI
In regard to: Re: [OpenIndiana-discuss] GPG2 on OI, Andreas Wacknitz said...: Am 04.10.21 um 20:58 schrieb Tim Mooney via openindiana-discuss: In regard to: Re: [OpenIndiana-discuss] GPG2 on OI, Andreas Wacknitz said...: Nice work from you and the GnuPG developer. I propose to either open a ticket for it on https://www.illumos.org/projects/illumos-gate or post the results from your analysis on #illumos. Maybe some illumos maintainers find it interesting enough to fix this problem in ilumos-gate. Robert Mustacchi has already implemented the necessary functionality in the Illumos kernel, see comment #2: https://www.illumos.org/issues/14126 Andreas, will OI's build system pick this up automatically, or is there something else I need to be able to do to test it for him? It will only picked automatically by our build system after it has been merged into illumos-gate. If you need to test it before you'll need to get the patch and apply it to our illumos-gate sources. The sources are located in the repository at oi-userland/components/openindiana/illumos-gate. Running "gmake publish" there will publish all illumos-gate related packages into your own local repository (which you have created before by running "gmake setup" in the oi-userland base folder). When you successfully published a patched version of the illumos-gate packages you'll need to intall them on your system. You can read about the process in our documentation, eg. at http://docs.openindiana.org/dev/userland/ I've been through that process many times for oi-userland packages I've updated or patched, but never for something from illumos-gate. I'll see if I can get the patch and get it tested. Thanks, Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure / Division of Information Technology/701-231-1076 (Voice) North Dakota State University, Fargo, ND 58105-5164 ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] GPG2 on OI
Am 04.10.21 um 20:58 schrieb Tim Mooney via openindiana-discuss: In regard to: Re: [OpenIndiana-discuss] GPG2 on OI, Andreas Wacknitz said...: Nice work from you and the GnuPG developer. I propose to either open a ticket for it on https://www.illumos.org/projects/illumos-gate or post the results from your analysis on #illumos. Maybe some illumos maintainers find it interesting enough to fix this problem in ilumos-gate. Robert Mustacchi has already implemented the necessary functionality in the Illumos kernel, see comment #2: https://www.illumos.org/issues/14126 Andreas, will OI's build system pick this up automatically, or is there something else I need to be able to do to test it for him? It will only picked automatically by our build system after it has been merged into illumos-gate. If you need to test it before you'll need to get the patch and apply it to our illumos-gate sources. The sources are located in the repository at oi-userland/components/openindiana/illumos-gate. Running "gmake publish" there will publish all illumos-gate related packages into your own local repository (which you have created before by running "gmake setup" in the oi-userland base folder). When you successfully published a patched version of the illumos-gate packages you'll need to intall them on your system. You can read about the process in our documentation, eg. at http://docs.openindiana.org/dev/userland/ Regards, Andreas ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] GPG2 on OI
In regard to: Re: [OpenIndiana-discuss] GPG2 on OI, Andreas Wacknitz said...: Nice work from you and the GnuPG developer. I propose to either open a ticket for it on https://www.illumos.org/projects/illumos-gate or post the results from your analysis on #illumos. Maybe some illumos maintainers find it interesting enough to fix this problem in ilumos-gate. Robert Mustacchi has already implemented the necessary functionality in the Illumos kernel, see comment #2: https://www.illumos.org/issues/14126 Andreas, will OI's build system pick this up automatically, or is there something else I need to be able to do to test it for him? Thanks, Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure / Division of Information Technology/701-231-1076 (Voice) North Dakota State University, Fargo, ND 58105-5164 ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] GPG2 on OI
Am 04.10.21 um 05:50 schrieb Tim Mooney via openindiana-discuss: In regard to: Re: [OpenIndiana-discuss] GPG2 on OI, Andreas Wacknitz said...: Today I have updated pinentry to the latest 1.2.0 version and also switched from curses to ncurses. My hope is that this will solve many reported problems. Hmmm, I did say I was working with the gnupg developers on that issue too, and I mentioned on the oi-devel list I was going to update pinentry, but if you prefer this approach, that's fine. I will close the ticket I opened against pinentry. Tim You can keep the ticket open. We will see whether they can fix the issues with curses. We can go back to curses any time the problem is fixed. Andreas ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] GPG2 on OI
Am 10/2/21 um 1:01 PM schrieb s...@pandora.be: - Op 1 okt 2021 om 20:25 schreef Discussion list for OpenIndiana openindiana-discuss@openindiana.org: In regard to: Re: [OpenIndiana-discuss] GPG2 on OI, s...@pandora.be said...: Do we know whether the GNUPG developers are testing/developing with GNU libncurses ? Or whether they have access to a more traditional UNIX system with older original style, AT or BSD curses ? The code is written to support both, though being a GNU project their primary focus is ncurses. According to https://en.wikipedia.org/wiki/Ncurses, ncurses is (nowadays) part of the GNU project but, under a permissive free software licence, similar to the MIT License. As a test I rebuilt the pinentry package to use libncurses : COMPONENT_NAME=pinentry COMPONENT_VERSION= 1.1.0 +COMPONENT_REVISION=1 COMPONENT_SRC= $(COMPONENT_NAME)-$(COMPONENT_VERSION) COMPONENT_PROJECT_URL= http://www.gnupg.org/related_software/pinentry/ COMPONENT_ARCHIVE= $(COMPONENT_SRC).tar.bz2 @@ -65,7 +66,6 @@ CONFIGURE_OPTIONS += --infodir=$(CONFIGURE_INFODIR) CONFIGURE_OPTIONS += --enable-pinentry-curses CONFIGURE_OPTIONS += --enable-pinentry-gtk2 CONFIGURE_OPTIONS += --disable-pinentry-qt -CONFIGURE_OPTIONS += --disable-ncurses CONFIGURE_OPTIONS += --disable-pinentry-fltk build: $(BUILD_64) @@ -84,6 +84,7 @@ test: $(NO_TESTS) REQUIRED_PACKAGES += library/desktop/gtk2 REQUIRED_PACKAGES += library/glib2 REQUIRED_PACKAGES += library/libsecret +REQUIRED_PACKAGES += library/ncurses This builds ok and it is possible to install that version: # pkg list -af pinentry security/pinentry 1.1.0-2020.0.1.0 --- security/pinentry (userland) 1.1.0-2020.0.1.1 i-- It uses libncurses: # ldd /usr/lib/pinentry-curses ... libncurses.so.5 => /usr/lib/64/libncurses.so.5 It seems that when I use text login console with TERM=sun-color, it now displays a frame. It looks decent. I can enter a passphrase and it works. However it is unclear to me whether this is the right approach (to use libncurses). That approach is not necessarily the right one. It changes the dependencies $ pkg contents -t depend pinentry TYPEFMRI ... require pkg:/library/ncurses@6.2.20200212-2020.0.1.1 ... require pkg:/system/library@0.5.11-2020.0.1.20711 The version with libncurses still has issues. With the TERM=xterm-256color the frame looks weird, even with libncurses. So it is not solving all problems, although that it solves the sun-color TERM problem. David Stes ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss Hi, Today I have updated pinentry to the latest 1.2.0 version and also switched from curses to ncurses. My hope is that this will solve many reported problems. Regards, Andreas ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] GPG2 on OI
- Op 1 okt 2021 om 20:25 schreef Discussion list for OpenIndiana openindiana-discuss@openindiana.org: > In regard to: Re: [OpenIndiana-discuss] GPG2 on OI, s...@pandora.be said...: > >> Do we know whether the GNUPG developers are testing/developing with GNU >> libncurses ? >> >> Or whether they have access to a more traditional UNIX system with older >> original style, AT or BSD curses ? > > The code is written to support both, though being a GNU project their > primary focus is ncurses. According to https://en.wikipedia.org/wiki/Ncurses, ncurses is (nowadays) part of the GNU project but, under a permissive free software licence, similar to the MIT License. As a test I rebuilt the pinentry package to use libncurses : COMPONENT_NAME=pinentry COMPONENT_VERSION= 1.1.0 +COMPONENT_REVISION=1 COMPONENT_SRC= $(COMPONENT_NAME)-$(COMPONENT_VERSION) COMPONENT_PROJECT_URL= http://www.gnupg.org/related_software/pinentry/ COMPONENT_ARCHIVE= $(COMPONENT_SRC).tar.bz2 @@ -65,7 +66,6 @@ CONFIGURE_OPTIONS += --infodir=$(CONFIGURE_INFODIR) CONFIGURE_OPTIONS += --enable-pinentry-curses CONFIGURE_OPTIONS += --enable-pinentry-gtk2 CONFIGURE_OPTIONS += --disable-pinentry-qt -CONFIGURE_OPTIONS += --disable-ncurses CONFIGURE_OPTIONS += --disable-pinentry-fltk build: $(BUILD_64) @@ -84,6 +84,7 @@ test: $(NO_TESTS) REQUIRED_PACKAGES += library/desktop/gtk2 REQUIRED_PACKAGES += library/glib2 REQUIRED_PACKAGES += library/libsecret +REQUIRED_PACKAGES += library/ncurses This builds ok and it is possible to install that version: # pkg list -af pinentry security/pinentry 1.1.0-2020.0.1.0 --- security/pinentry (userland) 1.1.0-2020.0.1.1 i-- It uses libncurses: # ldd /usr/lib/pinentry-curses ... libncurses.so.5 => /usr/lib/64/libncurses.so.5 It seems that when I use text login console with TERM=sun-color, it now displays a frame. It looks decent. I can enter a passphrase and it works. However it is unclear to me whether this is the right approach (to use libncurses). That approach is not necessarily the right one. It changes the dependencies $ pkg contents -t depend pinentry TYPEFMRI ... require pkg:/library/ncurses@6.2.20200212-2020.0.1.1 ... require pkg:/system/library@0.5.11-2020.0.1.20711 The version with libncurses still has issues. With the TERM=xterm-256color the frame looks weird, even with libncurses. So it is not solving all problems, although that it solves the sun-color TERM problem. David Stes ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] GPG2 on OI
- Op 30 sep 2021 om 20:41 schreef Discussion list for OpenIndiana openindiana-discuss@openindiana.org: >> Basically the fix is to put "s2k-count 29176832" in gpg-agent.conf : > > I didn't mention that in my previous post because it's not a fix, > just a workaround. Well I just tested on an older OpenIndiana machine (not running the latest OI hipster) that the solution also works for GNUPG 2.2.27. I call it now a solution - to avoid the word fix or workaround. As an experiment I put in my $HOME/.gpg/gpg-agent.conf the line: s2k-count 3 to use a different value but that also works. With gnupg 2.2.27 the gpg2 --gen-key works and is not hanging as it was in the past. I like to think of this solution (the line in the gpg-agent.conf) as a fix for a bug in GNUPG. My reasoning is that GNUPG is not forced at all to use any value as defined in system header files, so I would think that it is a bug in GPG2 in the first place. The report for the Illumos is interesting of course but still -- GNUPG2 could work (as the s2k-count line proves regardless of the support in the Illumos osnet-incorporation. By using the line in the gpg-agent.conf I can fix it without upgrading OpenIndiana ... which is a useful property of this solution or fix. For example I believe the build-essential IPS package group (metapackage) depends on gnupg. Regards David Stes ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] GPG2 on OI
- Op 30 sep 2021 om 22:29 schreef Discussion list for OpenIndiana openindiana-discuss@openindiana.org: > In regard to: Re: [OpenIndiana-discuss] GPG2 on OI, s...@pandora.be said...: > >> If I try it on X11/MATE desktop, >> then the default /usr/bin/pinentry works using the link to the >> /usr/lib/pinentry-gtk2, >> and it asks a passphrase and that works. >> >> If I alt+ctrl+F2 to start a console on vt2 (text console) using >> >> online 19:11:44 svc:/system/console-login:vt2 >> >> and then try it in text mode using TERM=sun-color and modify the >> gpg-agent.conf >> to set: >> >> pinentry-program /usr/lib/pinentry-curses >> >> then it uses the curses pinentry but it does not seem to work on the >> text-console sun-color for me, screen goes blank, no decent curses >> interface ... > > David, can I get you to test something? > > Repeat the console test you tried, but instead of using TERM=sun-color, > try > > TERM=vt100; export TERM > > and then run the test. > > I'm seeing much different behavior between TERM=xterm and TERM=vt100 > for pinentry, I'm wondering if you get the same results. > > Thanks, > > Tim when I change on the text login console the TERM from sun-color to vt100, the pinentry-curses draws a rectangle as follows : l q k x x x x m q j with characters l,k,m,j in the corners and x vertical bar and q horizontal bar It looks a little ugly but it is visible and indeed more usable. pinentry-curses is linked against libcurses.so from pkg:/system/library. That is, it uses /usr/lib/libcurses.so There is also the GNU libncurses on OpenIndiana .. That is pkg:/library/ncurses. I just checked a OmniOS CE community edition install the OmniOS gnupg pinentry uses libncurses ... it draws a nicer rectangle. The OmniOS omnios-extra repository seems to use libncurses for pinentry. Do we know whether the GNUPG developers are testing/developing with GNU libncurses ? Or whether they have access to a more traditional UNIX system with older original style, AT or BSD curses ? See history of BSD curses and AT curses at https://en.wikipedia.org/wiki/Curses_%28programming_library%29 Regards David Stes ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] GPG2 on OI
In regard to: Re: [OpenIndiana-discuss] GPG2 on OI, Andreas Wacknitz said...: Nice work from you and the GnuPG developer. I propose to either open a ticket for it on https://www.illumos.org/projects/illumos-gate or post the results from your analysis on #illumos. Maybe some illumos maintainers find it interesting enough to fix this problem in ilumos-gate. Done. https://www.illumos.org/issues/14126 Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure / Division of Information Technology/701-231-1076 (Voice) North Dakota State University, Fargo, ND 58105-5164 ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] GPG2 on OI
I just tested the fix that Tim and the GNUPG support found/provided. According to the bug report https://dev.gnupg.org/T5623 Basically the fix is to put "s2k-count 29176832" in gpg-agent.conf : $ cat $HOME/.gnupg/gpg-agent.conf # bug in GPG2 agent 'String to Key' see https://dev.gnupg.org/T5623 s2k-count 29176832 After a check that the gpg-agent is killed/restarted (using gpgconf --kill all), then gpg2 2.3.2 generates a key now for me using : gpg2 --gen-key. So the fix works ... to avoid the hang with GPG2 2.3.2 on --gen-key. Whether this is a Illumos / OpenIndiana or GNUPG2 issue, is unclear to me. But if there is some documentation that simply says that the gpg-agent.conf can contain the line that sets s2k-count then the issue is moot. Regarding the pinentry I can confirm that it acts buggy for me. If I try it on X11/MATE desktop, then the default /usr/bin/pinentry works using the link to the /usr/lib/pinentry-gtk2, and it asks a passphrase and that works. If I alt+ctrl+F2 to start a console on vt2 (text console) using online 19:11:44 svc:/system/console-login:vt2 and then try it in text mode using TERM=sun-color and modify the gpg-agent.conf to set: pinentry-program /usr/lib/pinentry-curses then it uses the curses pinentry but it does not seem to work on the text-console sun-color for me, screen goes blank, no decent curses interface ... However based on the bug report at gnupg.org this may be a totally unrelated issue or bug. So there are multiple issues with GPG2 ... I wonder whether there is some interest in packaging the old "legacy" PGP 1.4.23. When I wrote in my previous email that I read on the GNUPG website that PGP 1.4.23 is 'end of life' that is slightly incorrect, they write that it is "legacy" there, not end of life. Using a "mediator" it is perhaps possible to choose between PGP2 and PGP1 ! Because GNUPG write: "GnuPG 1.4 is the old, single binary version which still support the unsafe PGP-2 keys. This branch has no dependencies on the above listed libraries or the Pinentry. However, it lacks many modern features and will receive only important updates." it still implies that it gets "important updates" so it may still be an option ... David Stes - Op 30 sep 2021 om 17:56 schreef Andreas Wacknitz a.wackn...@gmx.de: > Am 9/30/21 um 10:37 AM schrieb Tim Mooney via openindiana-discuss: >> In regard to: Re: [OpenIndiana-discuss] GPG2 on OI, s...@pandora.be >> said...: >> >>> It is perhaps possible to try out older versions and find a solution, >>> I'd be interested if you find a solution and are willing to share it ! >> >> I reported the issue to the GnuPG bug tracker and have been working with >> one of the developers (gniibe) to diagnose the problem. He or she >> tracked >> the hang down really quickly. >> >> It's an issue with clock_gettime(). Both Solaris < 11.4 and the Illumos >> kernel define CLOCK_THREAD_CPUTIME_ID for thread interval timing, but >> it's effectively broken. Calling clock_gettime with >> CLOCK_THREAD_CPUTIME_ID as the first argument will always result in >> an EINVAL error return. Because CLOCK_THREAD_CPUTIME_ID is actually >> defined in the headers, though, the threading code in gpg-agent is trying >> to use it. >> >> Note that Solaris 11.4 added working CLOCK_THREAD_CPUTIME_ID, so >> clock_gettime() with CLOCK_THREAD_CPUTIME_ID works for latest OG Solaris, >> but not older versions or any Illumos (currently). Another place where >> the distros have now diverged. >> >> There's a Python bug report about the issue that the GnuPG developer >> referenced: >> >> https://bugs.python.org/issue35455 >> >> The developer is going to fix it in the gnupg mainline, so I expect gnupg >> 2.3.3 or 2.3.4 will have the hang fixed. >> >> I'll follow-up again as things progress with this issue and with the >> (apparently unrelated) issue with pinentry-curses drawing. >> >> Tim > > Hi, > > Nice work from you and the GnuPG developer. I propose to either open a > ticket for it on https://www.illumos.org/projects/illumos-gate > or post the results from your analysis on #illumos. Maybe some illumos > maintainers find it interesting enough to fix this problem in ilumos-gate. > > Andreas > > > ___ > openindiana-discuss mailing list > openindiana-discuss@openindiana.org > https://openindiana.org/mailman/listinfo/openindiana-discuss ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] GPG2 on OI
Am 9/30/21 um 10:37 AM schrieb Tim Mooney via openindiana-discuss: In regard to: Re: [OpenIndiana-discuss] GPG2 on OI, s...@pandora.be said...: It is perhaps possible to try out older versions and find a solution, I'd be interested if you find a solution and are willing to share it ! I reported the issue to the GnuPG bug tracker and have been working with one of the developers (gniibe) to diagnose the problem. He or she tracked the hang down really quickly. It's an issue with clock_gettime(). Both Solaris < 11.4 and the Illumos kernel define CLOCK_THREAD_CPUTIME_ID for thread interval timing, but it's effectively broken. Calling clock_gettime with CLOCK_THREAD_CPUTIME_ID as the first argument will always result in an EINVAL error return. Because CLOCK_THREAD_CPUTIME_ID is actually defined in the headers, though, the threading code in gpg-agent is trying to use it. Note that Solaris 11.4 added working CLOCK_THREAD_CPUTIME_ID, so clock_gettime() with CLOCK_THREAD_CPUTIME_ID works for latest OG Solaris, but not older versions or any Illumos (currently). Another place where the distros have now diverged. There's a Python bug report about the issue that the GnuPG developer referenced: https://bugs.python.org/issue35455 The developer is going to fix it in the gnupg mainline, so I expect gnupg 2.3.3 or 2.3.4 will have the hang fixed. I'll follow-up again as things progress with this issue and with the (apparently unrelated) issue with pinentry-curses drawing. Tim Hi, Nice work from you and the GnuPG developer. I propose to either open a ticket for it on https://www.illumos.org/projects/illumos-gate or post the results from your analysis on #illumos. Maybe some illumos maintainers find it interesting enough to fix this problem in ilumos-gate. Andreas ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] GPG2 on OI
In regard to: Re: [OpenIndiana-discuss] GPG2 on OI, s...@pandora.be said...: It is perhaps possible to try out older versions and find a solution, I'd be interested if you find a solution and are willing to share it ! I reported the issue to the GnuPG bug tracker and have been working with one of the developers (gniibe) to diagnose the problem. He or she tracked the hang down really quickly. It's an issue with clock_gettime(). Both Solaris < 11.4 and the Illumos kernel define CLOCK_THREAD_CPUTIME_ID for thread interval timing, but it's effectively broken. Calling clock_gettime with CLOCK_THREAD_CPUTIME_ID as the first argument will always result in an EINVAL error return. Because CLOCK_THREAD_CPUTIME_ID is actually defined in the headers, though, the threading code in gpg-agent is trying to use it. Note that Solaris 11.4 added working CLOCK_THREAD_CPUTIME_ID, so clock_gettime() with CLOCK_THREAD_CPUTIME_ID works for latest OG Solaris, but not older versions or any Illumos (currently). Another place where the distros have now diverged. There's a Python bug report about the issue that the GnuPG developer referenced: https://bugs.python.org/issue35455 The developer is going to fix it in the gnupg mainline, so I expect gnupg 2.3.3 or 2.3.4 will have the hang fixed. I'll follow-up again as things progress with this issue and with the (apparently unrelated) issue with pinentry-curses drawing. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure / Division of Information Technology/701-231-1076 (Voice) North Dakota State University, Fargo, ND 58105-5164 ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] GPG2 on OI
- Op 27 sep 2021 om 11:09 schreef Discussion list for OpenIndiana openindiana-discuss@openindiana.org: > > Thanks for the response David, I really appreciate it. I'm glad to see > it's not just my install. It is also possible to setup a test VM (for example with "vagrant") and make a new VM (scratch new environment) and install GPG2 and see that it hangs there. However it is possible that my command : gpg2 --gen-key is the wrong command, although I thought that was the way to generate keys. I'm no gpg expert. >> What I do as workaround is use "loopback" mode, I'm not sure whether you >> tried that, from reading your posting I think you may have already tried >> that : > > I hadn't, but I gave it a try and did get gpg2 to prompt for a passphrase, > but as you've also experienced, it hangs after accepting the passphrase. It is possible to compile the old GPG (not gpg2) vagrant@openindiana:~/gnupg-1.4.23$ gpg --version gpg (GnuPG) 1.4.23 Copyright (C) 2015 Free Software Foundation, Inc. with that old and unsupported "end of life" version, it still works to generate keys (old style) gpg: /export/home/vagrant/.gnupg/trustdb.gpg: trustdb created public and secret key created and signed. With gpg 1.4.23 (which fortunately still compiles fine on the latest OpenIndiana) the command : gpg --gen-key works for me. However there is a world of difference between those old versions and the new GPG 2.x series, so this probably does not provide a lot of value. It is perhaps possible to try out older versions and find a solution, I'd be interested if you find a solution and are willing to share it ! Thanks, David Stes ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] GPG2 on OI
In regard to: Re: [OpenIndiana-discuss] GPG2 on OI, s...@pandora.be said...: I can confirm I've had for the last months some annoying (blocking!) issues with GPG2 on OI, but some issues also happen on other operating systems (pin entry related), so this may be a GPG2 issue, and not an OI issue. Anyway ... Thanks for the response David, I really appreciate it. I'm glad to see it's not just my install. What I do as workaround is use "loopback" mode, I'm not sure whether you tried that, from reading your posting I think you may have already tried that : I hadn't, but I gave it a try and did get gpg2 to prompt for a passphrase, but as you've also experienced, it hangs after accepting the passphrase. My debugging seems to indicate that the pinentry programs work as expected. I don't think either pinentry-gtk-2 or pinentry-curses are to blame, because if I run one directly, like: /usr/lib/pinentry-curses and then enter the following commands (use the 'tty' command to get your correct ttyname first, each command should result in an OK response): SETTITLE This is my title OPTION ttyname=/dev/pts/5 OPTION ttytype=vt100 OPTION lc-ctype=en_US.UTF-8 SETPROMPT Enter your Passphrase: SETDESC Passphrase to get more Cookies! GETPIN Once you issue the GETPIN, it should draw the dialog and let you enter a passphrase, which it will echo back to you after you press enter. I've tried truss with various operations and it seems like gpg2 is having trouble communicating over the UNIX socket with the running agent. I've also discovered that after one of these apparently failed communications, the gpg-agent process starts accumulating CPU time at a rapid rate. I've also found when that happens that gpgconf --kill gpg-agent does not work. $ gpg2 --pinentry-mode loopback --gen-key Currently I have installed version 2.3.2 $ gpg2 --version gpg (GnuPG) 2.3.2 libgcrypt 1.9.4 Same versions I'm using. This comes from $ pkg list gnupg libgcrypt NAME (PUBLISHER) VERSIONIFO crypto/gnupg 2.3.2-2020.0.1.0 i-- system/library/security/libgcrypt 1.9.4-2020.0.1.0 i-- Unfortunately even if I use "loopback" mode GPG2 is not working for me on OI. For example when I try $ gpg2 --pinentry-mode loopback --gen-key It hangs on: We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. After a while I abort, no key is generated for me ... It hangs for me after multiple different operations too, including decrypting a text file that was encrypted for my ID on a different system. Anyway, thanks for confirming you're seeing similar issues. I'll report back to the mailing list if I make any progress debugging it. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure / Division of Information Technology/701-231-1076 (Voice) North Dakota State University, Fargo, ND 58105-5164 ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] GPG2 on OI
Hi, I can confirm I've had for the last months some annoying (blocking!) issues with GPG2 on OI, but some issues also happen on other operating systems (pin entry related), so this may be a GPG2 issue, and not an OI issue. Anyway ... What I do as workaround is use "loopback" mode, I'm not sure whether you tried that, from reading your posting I think you may have already tried that : $ gpg2 --pinentry-mode loopback --gen-key Currently I have installed version 2.3.2 $ gpg2 --version gpg (GnuPG) 2.3.2 libgcrypt 1.9.4 This comes from $ pkg list gnupg libgcrypt NAME (PUBLISHER) VERSIONIFO crypto/gnupg 2.3.2-2020.0.1.0 i-- system/library/security/libgcrypt 1.9.4-2020.0.1.0 i-- Unfortunately even if I use "loopback" mode GPG2 is not working for me on OI. For example when I try $ gpg2 --pinentry-mode loopback --gen-key It hangs on: We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. After a while I abort, no key is generated for me ... David Stes - Op 27 sep 2021 om 4:51 schreef Discussion list for OpenIndiana openindiana-discuss@openindiana.org: > All- > > Anyone else using GnuPG on OI? I'm seeing some strange/broken behavior > somewhere between gpg2, gpg-agent, and pinentry. I'm wondering if it's > something with my install (or environment), or if others are having issues > too. > > Basically, when gpg2 does something that needs a passphrase, it's supposed > to contact the gpg-agent, auto-starting it if necessary, and then the > gpg-agent uses one of the pinentry programs for the actual prompting. > > When I try ssh into my OI workstation and use gpg2, whatever is going on > causes the (curses) pinentry screen to be blank. > > I know it's not a problem with pinentry-curses, because I can interact > with it directly and send the necessary "commands" via the "assuan" > protocol to get it to display a password prompt window and correctly > collect a password. > > I've also had problems with gpg2 hanging and not exiting even after some > operations. > > I'm just wondering if anyone else is seeing similar issues, or if I need > to look more closely at what might be wrong with my environment. > > Thanks, > > Tim > -- > Tim Mooney tim.moo...@ndsu.edu > Enterprise Computing & Infrastructure / > Division of Information Technology/701-231-1076 (Voice) > North Dakota State University, Fargo, ND 58105-5164 > > ___ > openindiana-discuss mailing list > openindiana-discuss@openindiana.org > https://openindiana.org/mailman/listinfo/openindiana-discuss ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
