Why 2.1 is delayed for so long

[Daniel Kahn Gillmor]

[cc'ing debian's pkg-gnupg-maint mailing list, since this discussion is
relevant there]

On 09/19/2014 08:30 AM, Ximin Luo wrote:
> On 19/09/14 09:49, Werner Koch wrote:
>> On Thu, 18 Sep 2014 02:25, djhaskin987 at gmail.com said:
>>
>>> also seen Werner say on this mailing list that he has used 2.1 "for
>>> years now". I wonder if there is a measure by which the four-year-old
>>> version shall be considered stable. If so, what is it? If not, or if
>>
>> Never change a running system (i.e. 1.4).  I am glad to see that after
>> 11 years 2.0 is now going mainstream.
>>
>> I assume that 2.1 will be be adopted faster because it has improvements
>> which are fashionable now; in particular ECC.  However, ECC is also one
>> of the problems why 2.1 is delayed.  The plan is to implement the new
>> non-TLA created ECC curves (Curve255519).  Last fall it looked that the
>> IETF would fast adopt they as standards but they keep on debating.  Thus
>> the likely outcome is that 2.1 will be released without an official IETF
>> standard for the new curves.
>>
>> I did a new beta yesterday but my experience with beta versions is that
>> they are not widely used or problems/success are not reported.  To move
>> forward we might have to jump into cold water and release 2.1 without
>> having many test results.  And I need to set aside enough time to
>> quickly work on reported problems after 2.1.0.  Thus all other
>> construction areas should be cleaned up before.
> 
> FWIW I would be happy to help test, if someone makes a Debian package for gnupg 2.1. I might do that myself this weekend. Let me know if there's any significant installation differences between 2.0 and 2.1.

I've packaged the latest beta for gnupg 2.1, with the idea of shipping
it in debian experimental, but i'm reluctant to distribute it in debian
yet for a couple reasons (which i'll go into below, thanks for prompting
me to write this up).

If you want to build and install it yourself, you should be able to do
so from git (the repo is about 25MiB):

 git clone git://anonscm.debian.org/pkg-gnupg/gnupg2.git
 cd gnupg2
 git checkout upstream-2.1
 git checkout pristine-tar
 git checkout experimental
 git-buildpackage -uc -us

This should produce .deb files for you in ../

Note that these will replace any existing gnupg2 packages on your debian
system!

the current head of the experimental branch is:
5239f4155a7b8bc773a5d490ff4c61c1280d61ed

OK, so why am i not ready to upload this to debian's experimental
repository yet?  I see three outstanding concerns, the first two of
which are relevant for upstream:

 0) reverse compatibility of ~/.gnupg/pubring.gpg with earlier gnupg
1.4.x and 2.0.x

When a new keyring is created with 2.1 in ~/.gnupg/pubring.gpg, it is
created in a keybox format.  This format is unreadable by gnupg 1.4.x
and 2.0.x.  So GNUPGHOME directories created by 2.1 will be unusable by
older versions.  Given that the older versions aren't going away in the
short term, this seems problematic.

Why not use ~/.gnupg/pubring.kbx, as documented in the man page?  In the
event that both versions coexist, synchronizing the two files  (or at
least updating the .kbx from changes to the .gpg) seems like a pain, but
it seems more manageable than simply making 1.4.x or 2.0.x unusable in
the event that the keybox-formatted pubring.gpg exists.

(i think earlier betas actually aggressively transformed the pubring.gpg
into a keybox format when run, which was even worse than the current
situation; beta834 seems to only present the problem for new GNUPGHOME
directories)

 2) interactions between running gpg-agent and newer gnupg2

One common upgrade path i can imagine is this, especially during the
experimental phase:

 * user decides "i want to try this new, fancy gpg 2.1".  from within
their graphical desktop, which already has gpg-agent 2.0.x running, they
do: "sudo apt-get install -t experimental gnupg2"

 * then, immediately, they want to try out the fancy goods, so they run
gpg2.  gpg2 tries to talk to the running agent, but the running agent is
the old agent, not the new agent.  the upgrade process fails weirdly
(while claiming success!):


gpg: starting migration from earlier GnuPG versions
gpg: porting secret keys from '/home/foo/.gnupg/secring.gpg' to gpg-agent
gpg: error getting the KEK: Unknown IPC command
gpg: migration succeeded

clearsigning a message also fails:

gpg: signing failed: Unsupported protection
gpg: [stdin]: clearsign failed: Unsupported protection

or sometimes:

gpg: signing failed: Provided object is too short
gpg: [stdin]: clearsign failed: Provided object is too short


So i think that gpg2.1 needs to somehow detect that the running agent is
old, and either fail more gracefully (making it clear to the user  or
actually restart the agent if it can be sure that gpg-agent is the right
version.

 0) dirmngr

gpg2.1 depends on the latest version of dirmngr for any/all of its
remote access functionality (e.g. keyserver fetches).  Debian has
traditionally packaged dirmngr separately from gnupg, but it looks like
we should really bring the two of them together.  This is is
debian-specific packaging work; we've already gotten permission of the
dirmngr maintainer to do this, so it's just outstanding work that needs
to be done:

http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/2014-September/001828.html

I welcome any feedback and suggestions on these issues.

happy hacking,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140919/eee6789a/attachment.sig>