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

[Andre Heinecke]

Hi,

On Friday 15 April 2016 11:09:41 Werner Koch wrote:
> 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.

Yes and that is good but still it is another migration to a new format. The 
migration from 2.0 to 2.1 with the new secret key storage is painful enough my 
initial reaction was that I'm scared of another migration so that GNUPGHOME 
will be incompatible between different distributions I use. But thinking a bit 
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 < 
2.1.11 but > 2.1.0 is used in parallel with a 2.3 version.

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

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

Just to be clear, I'm not talking about the actual key material but the 
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-
agent should not link with sqlite. So I'm agreeing here that sqlite would not 
be a good option.

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

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 and have 
another migration.

Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160415/34efbc5a/attachment.sig>