Why 2.1 is delayed for so long

[Werner Koch]

On Fri, 19 Sep 2014 16:35, dkg at fifthhorseman.net said:

> the current head of the experimental branch is:
> 5239f4155a7b8bc773a5d490ff4c61c1280d61ed

i.e. with your own changes.  I assume it is based on beta834 (commit
93f158df)

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

I do not have this problem, but let's see:

> 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

Well, that is a bug.  A newly created file should be named this and not
".gpg".

> 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 agree.  Syncinging is easy, though: "gpg1 --export | gpg2 --import"

> (i think earlier betas actually aggressively transformed the pubring.gpg
> into a keybox format when run, which was even worse than the current

No they they didn't.  You might have got the impression because gpgsm
has always created a "pubring.kbx".

I really want to use the keybox format for new keys.  If an existing
pubring.gpg exists, gpg2.1 will continue to use that and not the kbx
format.

>  * 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!):

Okay, what to do:

- Have gpg check the agent version and refuse all commands if it does
  not match its expectations (ie. for now the same version as gpg)

- Popup Pinentry to explain the situation

The latter has the advantage that it will give a clear error message
also if gpg is silently used by a fronend.

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

Restarting without user consent might be problematic.

>  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

The question is whether the old dirmnagr is at all useful.  How many are
using it to check CRLs or run OCSP checks for X.509?

Or would it be useful to rename the new dirmngr so that both can
co-exist?  The name is anyway alien to GnuPG. 



Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.