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

[Ian Jackson]

Daniel Kahn Gillmor writes ("Re: [pkg-gnupg-maint] Bug#841143: Suspected race in gpg1 to gpg2 conversion or agent startup"):
> can you clarify the race?  i'm afraid we've been arguing about the gnupg
> upgrade in several places and i'm happy to re-focus this particular
> ticket.

Sorry about that.  I guess I must be coming across as quite grumpy.
Please don't be discouraged.  Yes, let's refocus this bug.

> i think you're saying that if two different instances of 2.1
> concurrently try to upgrade a given 1.4.x homedir, one of them may
> intermittently fail.
> 
> Is that correct?  Do you have a narrower replication example than
> running dgit repeatedly?

I haven't tried to narrow the test case.  I'm not 100% sure that
concurrent execution of different gnupg instances is necessary.
My replication is with the dgit test suite, which does run dgit but
only in a self-contained way.

> > Can you at least make the migration work every time ?
> 
> can you help me to replicate the migration failure?  from stretch, you
> can create a GNUPGHOME with gpg1 and try to trigger parallel upgrades.
> 
> I've done:
> 
>     export GNUPGHOME=$(mktemp -d)
>     gpg1 --gen-key
>     for x in 1 2 3 4 ; do
>        echo test $x | gpg --output test$x.gpg --clearsign &
>     done
>     wait %1 %2 %3 %4
> 
> and it seems to work fine on my 4-core machine.
> 
> Is there a better way to replicate?

I don't know.  You could try

   sudo apt-get install dgit dgit-infrastructure devscripts debhelper
   dgit clone dgit sid
   cd dgit
   tests/using-intree tests/run-all

and then look in

   test/tmp/NAME-OF-FAILED-TEST.log

Or you could give me a version of gnupg2 which prints a better error
message or instructions for making it produce debugging output.
Currently I see, when it fails:

  gpg: starting migration from earlier GnuPG versions
  gpg: can't connect to the agent: IPC connect call failed

This doesn't say what the errno was.  (And is "IPC connect call" a
reference to connect(2) ?)

> > This is a very broad definition of "co-installable".  In practice an
> > admonition not to use gnupg1 and gnupg2 with the same ~ is going to be
> > impractical to comply with.
> 
> That's why i'm trying to help consolidate debian to only use a single
> gpg, and to support 1.4.x only for people with unusual/antique use
> cases.

In fact the other things in your mail were much more reassuring.  For
example, given the behaviour you describe, I can convert the test
suite's $GNUPGHOME once and it will work just fine with both gnupg1
and gnupg2.  If I add private keys later with gnupg2 then those won't
be visible to gnupg1, but for me that's kind of expected.

But I would like to nail the intermittent failure before I cover it up
by making the conversion happen much less often (and probably covered
by some kind of outer lock of my own)...

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.