[pkg-gnupg-maint] Bug#841143: Bug#841143: Suspected race in gpg1 to gpg2 conversion or agent startup
Ian Jackson
ijackson at chiark.greenend.org.uk
Thu Oct 20 00:12:01 UTC 2016
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.
More information about the pkg-gnupg-maint
mailing list