[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"):
> On Wed 2016-10-19 05:47:02 -0400, Ian Jackson wrote:
> > If gnupg doesn't guarantee that v1's will work with v2 then you don't
> > have an upgrade path for your users.
> 
> We do have an upgrade path currently from v1.4.x to v2.0.x and v2.1.x.
> However, i don't know whether GnuPG upstream is willing to guarantee
> that v1 will work with v2.4.x.  If you want things to be arbitrarily
> portable, you should use the portable data formats.

I think this bug #841143 is about a race in this upgrade path.  Do you
intend to investigate or fix this race ?

> > I'll take your answer as a declaration that downgrading is not
> > supported.  Unfortunately I think this means you have a bug.
> >
> > For example, consider schroots, which typically contain /home.
> 
> an schroot will also work when upgraded across single debian versions.

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.

I'm sorry to say that I think this all seems quite ill-advised.

> I'm afraid you're simply not going to get the fastest possible
> conversion if you do incur an upgrade during your test suite's
> migration.  sorry!

Can you at least make the migration work every time ?

> > Also there are institutions where all the home directories are on NFS.
> > Obviously one wouldn't recommend putting GNUPGHOME on NFS, but there
> > might be reasons why it's OK in context.
> >
> > In both of these situations the same ~ may be operated on by programs
> > from different Debian releases (or non-Debian operating systems) in
> > any arbitrary interleaved order.
> 
> I believe upstream is aware of this, which is why they've declared (for
> example) that gpg 2.0 and gpg 2.1 are not "co-installable".

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.

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.