[OpenIndiana-discuss] GPG2 on OI

[stes@PANDORA.BE]

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.Wacknitz at 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, stes at 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 at openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss