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
signature.asc
Description: PGP signature