Ian Jackson writes ("Re: Bug#841143: [pkg-gnupg-maint] Bug#841143: Suspected
race in gpg1 to gpg2 conversion or agent startup"):
> I have been digging in the code. I found it very difficult to get any
> useful debug logging out. Some patches to maybe help with that will
> follow, but I am still stumped as to get debugging output from
> gpg-agent. I tried making a stunt shell script to pass --debug-all
> --no-detach and redirect stderr somewhere, but it is ineffective for
> some reason.
The reason was that gpg closes all the fds when spawning gpg-agent.
Ian Jackson writes ("Re: Bug#841143: [pkg-gnupg-maint] Bug#841143: Suspected
race in gpg1 to gpg2 conversion or agent startup"):
> I fixed this but it didn't help. I now have a gdb onto a stuck agent,
> which has shutdown_pending but is stuck in select. I think
> shutdown_pending must have become 1 between the main loop test and the
> entry to select.
I have patches to fix these bugs and add some debugging. With these
patches my test suite seems to reliably run successfully to
completion. Without them I can repro the failure nearly every time.
I'll send the patches in a moment as a four-mail patchbomb.
> This approach to programming is a quite a rich seam of opportunities
> for threading bugs.
>
> For example, I think the variables `check_own_socket_running' and
> `shutdown_pending' are both accessed willy-nilly on multiple threads
> without locking.
Even with my patches, bugs remain. I only looked at the agent
startup/shutdown code. I fear for the rest of the code.
I am very concerned that there doesn't seem to be any systematic and
effective way to avoid threading bugs in gpg-agent.
Trying to write multithreaded C code in the mutex lock/unlock style,
without either serious coding style, code structure, and build system
support, or extensive use of state-of-the-art static or dynamic
analysis tools, almost inevitably leads to threading bugs like the
ones I have discovered.
I found no evidence of the kind of coding style/structure approach
that would avoid introduction of threading bugs through human error.
And the bugs I found so far demonstrate that there has been no
effective tool-based audit.
gpg-agent is AIUI the main program which handles key material. We
cannot afford for it to be afflicted by threading bugs.
Would you please consider a different approach ? For example, I think
the existing code structure might support use of fork rather than
threads.
Thanks,
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
