[PATCH 3/3] common: Add support for the new extended private key format.
wk at gnupg.org
Fri Apr 15 11:09:41 CEST 2016
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
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
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
More information about the Gnupg-devel