Daniel Kahn Gillmor writes ("Re: [pkg-gnupg-maint] Bug#841143: Suspected race
in gpg1 to gpg2 conversion or agent startup"):
> If you have a test suite that intends to use secret key material, and
> you want it to work across different versions of GnuPG, your test suite
> should not ship what it thinks is a GNUPGHOME. GnuPG doesn't guarantee
> that one version will necessarily work with the other's.
If gnupg doesn't guarantee that v1's will work with v2 then you don't
have an upgrade path for your users.
> Instead, if you have public or secret key material that you want any
> version of GnuPG to work with, you should ship that material in the
> standard OpenPGP transferable formats (e.g. the output of "gpg
> --export-keys" and "gpg --export-secret-keys"), and then import it at
> the start of the test suite while building the GNUPGHOME for the test
> suite to use.
This seems likely to be slower than what I previously had with gnupg1.
> The contents of any particular GNUPGHOME is not a part of the GnuPG API
> contract.
All I'm relying on is that in Debian, `gnupg' works with a $HOME that
was created with a previous version of `gnupg', even perhaps from an
earlier Debian release.
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.
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.
Ian.
--
Ian Jackson <ijack...@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.
