GPGME: Exporting private OpenPGP keys

[Marcus Brinkmann]

At Thu, 13 Jul 2006 22:36:29 +0200,
Mario Lenz <mario.lenz at gmx.net> wrote:
> Is there a reason why this function isn't part of GPGME? If it's just
> because you havn't had time yet: I would do it. I had a look at it and
> it seems that the easiest way would be to change:
> 
> if (reserved) return gpg_error (GPG_ERR_INV_VALUE);
> err = add_arg (gpg, "--export");
> 
> to:
> 
> if (reserved == 0) err = add_arg (gpg, "--export");
> else if (reserved == 1) err = add_arg (gpg, --export-secret-keys");
> else return gpg_error (GPG_ERR_INV_VALUE);
> 
> in functions gpg_export and gpg_export_ext (both gpgme/rungpg.c). Of
> course, you would loose the reserved parameter.

This would be how to do it.  In fact, I think the reserved parameter
was for this purpose, I think.  However from the TODO:

** New features requested by our dear users, but rejected or left for
   later consideration:
*** Allow to export secret keys.
    Rejected because this is conceptually flawed.  Secret keys on a
    smart card can not be exported, for example.

Note that the trend for the gpg suite goes towards putting more and
more secret-key related stuff into gpg-agent and friends, away from
gpg.  The idea is that handling the really sensitive data should be
done in as much of a contained space as possible.  Imagine the secret
key would be managed by gpg-agent, and that there would be a way to
export it (ie, it is not a smart card).  Then the path through GPGME
would be (square brackets [] denote a process)

(key repository ->) [gpg-agent] -> [gnupg] -> [gpgme -> application]

whereas application would often include several other layers, like
libqt for input/output, or libglib for storage allocation.

These are three processes at least, and at least one of them, the
application, will very likely not handle secure memory at all (take a
look at pinentry how difficult it is to use mix secure memory and a
GUI application).  Another one, gnupg, would not need to run with
secure memory in this model if secret key exports were not allowed
(that's the reason why we move this stuff to gpg-agent).

I do understand that there is another consideration, and that is that
users want to be able to do key management using their favourite email
program, and that this includes making backups of secret keys.  In
GPA, we do the same, by calling gnupg directly.  And yes, it would be
preferable to use a GPGME interface.

So, if you still think it is a good idea, and if Werner does not
object too strongly, I think I would accept such a patch that you
propose, just because it is a small change, and it is something that
many people want to do and because they are going to do it anyway, and
if they do it it's better to do it via GPGME.  But at least we need to
make it very clear in the documentation what the limits and caveats
are.

Thanks,
Marcus