[pkg-gnupg-maint] Bug#841143: Bug#841143: Suspected race in gpg1 to gpg2 conversion or agent startup [and 1 more messages]

[Ian Jackson]

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 <ijackson at 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.