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

[Werner Koch]

On Fri, 15 Apr 2016 09:38, aheinecke at intevation.de said:

> I feel a bit that this should have been discussed before implementing it. For 

As usual with new features we provide it on a read-only base first to
avoid backward compatibility problems.

> any changes to key storage (public or private) I would have argued to switch 
> to sqlite. The amount of Bugs and performance problems by using

That is a big fat no-go!  gpg-agent is designed to take good care of the
secret keys and thus we go into great lengths to protect them from
leaking.  Putting them in a SQL database is dangerous because we have no
control over the way they are stored and we would need to link gpg-agent
to a huge amount of extra code.  Direct use of the file system is a
better place for these objects.

> formats has been a problem in GnuPG in my (limited) experience.

The secret keys are stored one key per file and I am not aware of any
problems.  In fact we developed this format a decade ago with the
special purpose to store secret keys.

> and you would not need yet another GnuPG specific file format with a parser etc.  
> it would imo also solve your requirement to store meta data.

Nope.  It is already possible to store meta data in the key files.  We do
this for more than a decade.  However, it requires extra tools (as does
a SQL DB) which is admin unfriendly.  Also a textual representation is
always better than binary blurbs somewhere on the disk.

The immediate use cases for the new formats will be:

 - Allow to set a confirm flag for all kind of keys and not only for ssh
   use via the sshcontrol file.

 - Persistent store for ssh certificates for use by the ssh-agent
   protocol.

We will also take the opportunity of the new format to make use of
OCB-AES based protection of secret keys for those who need this (the
gpg4vs-nfd project).


Shalom-Salam,

   Werner

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