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

[Daniel Kahn Gillmor]

On Wed 2016-10-19 09:39:28 -0400, Ian Jackson wrote:
> I think this bug #841143 is about a race in this upgrade path.  Do you
> intend to investigate or fix this race ?

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.

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?

> No, I think you misunderstand.
>
> An schroot typically shares its /home with the "outside" system.
> People often use such chroots for running newer versions of things on
> an older system, or vice versa, whenever that's needed.
>
> If I have a jessie system with a stretch chroot, and I run `gnupg' in
> the stretch chroot, gnupg's conversion will mess up my ~/.gnupg so
> that my main system does not work any more.

That's not actually the case, fwiw.  gpg in the sid chroot will import
the keys from your secring.gpg into private-keys-v1.d/, and it will
create .gpg-v21-migrated, but it will not delete secring.gpg.

however, if you subsequently create new secret keys in secring.gpg from
jessie, those keys will not be visible to 2.1.x in future connections
(since it will think the migration is already done because of
.gpg-v21-migrated -- i've filed https://bugs.gnupg.org/gnupg/issue2811
as a minor improvement on this).

if you use gpg 2.1 to modify ~/.gnupg/gpg.conf to include options that
1.4.x doesn't know about or can't handle, then all bets are off.  but
the same is true for ~/.ssh/known_hosts and any other comparable
software-maintained file, right?

Would you consider it a bug in ssh if an ecdsa entry added to
~/.ssh/known_hosts by a newer version of ssh wouldn't be read
successfully by an older version of ssh?

> 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?

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

Thanks for helping make this change happen.

Regards,

       --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 930 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20161019/001f97b2/attachment.sig>