[PATCH 3/3] common: Add support for the new extended private key format.

[Werner Koch]

On Fri, 15 Apr 2016 11:35, aheinecke at intevation.de said:

> Yes and that is good but still it is another migration to a new format. The 

It is not a new format but but an update of an existsing format.

> migration from 2.0 to 2.1 with the new secret key storage is painful enough my 

This is unrelated.  We are talking only about files stored under
private-keys-v1.d which are an exclusive property of gpg-agent.  Neither
gpg nor gpgsm are involved.

> more about this It probably won't hurt as much as the 2.0 / 1 incompatibility 
> in secret key storage. As this only will be an additional problem if GnuPG < 

You mean OpenPGP keys in 2.1 and pre 2.1.  Actually it is not an
incompatibility but an upgrade path.  Once you switched to the new
storage method (ie. 2.1) you can't switch back with out 2 additional
steps.

Remeber that for ages I am talking that secring.gpg and pubring.gpg
shall never be used directly but only through --export and import
commands.

> (And I was hoping a bit for a migration to a versioned format (sql) to
> end all migrations)

SQL is not a way to end migrations but a way to clobber a DB schema with
insane data structures for the purpose of backward compatibility.  A
complex schema does not help to keep compatibility to old software
versions if you need to change that just that schema.

> encrypted files that are now in the filesystem. I don't see how putting this 
> data in a sqlite database would hurt security. But I see the point that gpg-

Because there are buffers which keep the keys in user space memory
longer than needed.

> Yes I see the need for additional meta-data that is read by gpg-agent. But is 
> there no way to store that meta data without breaking older versions? This 
> would remove the need to first add read support and then later use it

There won't be any breakage.  The new storage format will only be used
if the user explicitly requested that.  Right, older software versions
won't be able to read that format and thus can't use the key.  But that
is the same as with the new OCB-AES protection algorithm.  In theory we
could easily backport the new format to GnuPG 2.0.  But the format
will go along with the OCB-AES protection and that requires the use of
Libgcrypt 1.7 - I doubt that major distros will upgrade to Libgcrypt
1.7 just for this purpose.


Shalom-Salam,

   Werner

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