[pth] Hack pth to avoid segfault in pth_sigmask.

[dcaliste]

The pth_current seems to be ill-defined in gpg-agent, resulting in a segfault.

@Thaodan and @pvuorela , this is a very ugly fix to a segfault appearing in GnuPG agent. Let me detail:

• for the context, GnuPG is stuck at a very old and discontinued version that we cannot move at the moment for "political" reasons.
• gpg-agent when run in daemon mode (which was suggested by @Thaodan in [sailfish-secrets] Put the P2P DBus socket in a sub-directory of /run. Contributes to JB#56300 sailfish-secrets#178) is segfaulting on start-up. To reproduce, just run in a console gpg-agent --daemon --verbose. It will print the socket address for communication, but the child process actually segfault, as visible with gdb:

[Inferior 1 (process 8345) detached]
GPG_AGENT_INFO=/home/nemo/.gnupg/S.gpg-agent:8388:1; export GPG_AGENT_INFO;

Thread 2.1 "gpg-agent" received signal SIGSEGV, Segmentation fault.
[Switching to process 8388]
__GI___sigprocmask (how=how@entry=1, set=0x3cc, oset=oset@entry=0x0)
    at ../sysdeps/unix/sysv/linux/sigprocmask.c:38
38	      && (__builtin_expect (__sigismember (set, SIGCANCEL), 0)
(gdb) bt
#0  __GI___sigprocmask (how=how@entry=1, set=0x3cc, oset=oset@entry=0x0)
    at ../sysdeps/unix/sysv/linux/sigprocmask.c:38
#1  0xb6ee6be8 in pth_sigmask (how=how@entry=1, set=set@entry=0xbefff418, oset=oset@entry=0x0)
    at pth_high.c:136
#2  0x000148be in handle_connections (listen_fd_ssh=-1, listen_fd=4) at gpg-agent.c:1538
#3  main (argc=<optimized out>, argv=<optimized out>) at gpg-agent.c:1045

• the problem is in pth library, but I didn't find the root cause of the problem. My best guess is that pth_current is not properly initialised.

Now, looking at how they solved this in more modern versions of GnuPG brings me nowhere since GnuPG moved from this pth library to a new one npth with a different API. pth library 2.0.7 is the last one that exists and seems discontinued.

I've no idea if the following patch would break something actually. But at least the gpg-agent is now running, can be contacted from inside a jail and can open a lipstick system window asking for a password.

What do you think ?

[pvuorela]

Uh... seems tricky. Good thing is that pth seems to be used only by dirmngr and gnupg2 so any breakage is at least restricted. Bad thing is that the patch removes half of what the function was doing and thus might cause other problems.

For the actual bug, set=0x3cc doesn't look good indeed. At least the pth_current doesn't get assigned in many places so could hope there's some chance on finding the real problem.

[dcaliste]

Actually, I tried to see where pth_current is set and there is some code associating it in pth_sched.c. But after some debugging around 2 am last night I gave up. Strangely Valgrind is not reporting any use of uninitiated memory before the actual failure in pth_high.c. But it's surely some issue with uninitiated memory, because even a call to sigempty...(&(pth_current->mctx.sigs)) is failing if put at that place, while pth_current is not NULL and mctx.sigs is memory space in the type. So only one possibility remains here: pth_current pointer is pointing to a non-sense location. But I didn't find anything usefull in the pth_sched.c and such debugging is very time consuming because the code is somehow complex.

The best way to go would be update to npth but I'm afraid it's very invasive and requires a lot of work to backport it into old GnuPG 2.0.4. So my second choice was to patch pth. If I try to understand what the code I've removed is doing, it is about blocking / unblocking some Unix signals. Actually the code commented is blocking / unblocking some (current) signals before applying the user defined choice. All in all, it's just related to be able to intercept SIGHUP and friends in the agent. Which we don't care much about actually.

We have two choices here to solve the high level issue of email signing being broken :

• start the gpg-agent on demand (I'm currently adding systemd socket listeners for GnuPG) in user session and let the current GnuPG permissions (to access the ~/.gnupg directory with the agent socket) as they are so a jailed application can contact the gpg-agent which will contact the secret daemon. It requires to patch pth somehow.
• let the current way of working, which means that a transient PIPE-based gpg-agent is started for the current process (and don't suffer the pth bug) for each access to GnuPG stuff. Then, this transient agent has to contact the secret daemon for pinentry purposes. If the initial process is jailed, then we need to add new Secret permissions to allow the transient gpg-agent to reach out of the jail. This is the two PR in sailfish-secrets and sailjail-permissions.

The first one was suggested by @Thaodan and is cleaner in my opinion, and closer to how it is working on desktop. In fact modern GnuPG (when allowed) is putting its sockets in the /run/user directory in a subdir, and supervised by systemd out of the box. The second avoids patching pth (which may not be that bad after all), but means that GnuPG permissions would include secret daemon permissions too.

What do you think ?

[Thaodan]

* let the current way of working, which means that a transient PIPE-based gpg-agent is started for the current process (and don't suffer the `pth` bug) for each access to GnuPG stuff. Then, this transient agent has to contact the secret daemon for pinentry purposes. If the initial process is jailed, then we need to add new Secret permissions to allow the transient gpg-agent to reach out of the jail. This is the two PR in sailfish-secrets and sailjail-permissions.

Personally I would prefer first since all the arguments you have been already bringing up and separation is cleaner in the first approach since the process should be separated from gnupg especially when you consider that more apps could take to GNUPG at the same time.

[dcaliste]

To get the latest GnuPG, we need to upgrade pth to npth. I've packages it in https://github.com/dcaliste/npth. I don't know who can create a new repo in sailfishos. @Thaodan and @pvuorela, any idea ?