Inability to export and then import my secret key

[Mirimir]

On 08/12/2015 03:58 AM, Peter Lebbing wrote:
> On 12/08/15 04:00, Mirimir wrote:
>> It's simplest to just copy the gpg folder. Importing private keys is
>> broken by design.
> 
> I don't think I agree with either statement. Copying the folder comes
> with its own caveats: don't copy random_seed, and you might not want two
> identical installations with regard to present private keys and such.

I got that OP is migrating to new hardware, so I don't see why identical
installations would be problematic.

> And "broken by design" implies to me that GnuPG doesn't *want* to
> support merging secret keys; which would be odd given that the latest
> version, GnuPG 2.1, does support it. I also can't remember ever hearing
> a reason why it would be bad.

Well, GnuPG 1.4 _definitely_ doesn't support importing secret keys. But
maybe I'm wrong about "broken by design". I vaguely recall reading
something about that a year or two ago.

> Anyway, the reason I think Bryant is seeing this issue, is that GnuPG
> 1.4 and 2.0 don't support merging new things into existing secret keys.
> I suppose the key already existed on the other system but you added new
> subkeys and are trying to import those?
> 
> If you can get the up-to-date system (sys1) to export the secret key as
> you want it to be on the other computer (sys2), it boils down to:
> 
> sys1 $ gpg2 -o sec.gpg --export-secret-keys 1C0B95E5
> [copy sec.gpg to sys2]
> sys2 $ gpg2 -o sec_backup.gpg --export-secret-keys 1C0B95E5
> sys2 $ gpg2 --delete-secret-keys 1C0B95E5
> sys2 $ gpg2 --import sec.gpg
> 
> Now check if everything is okay on sys2, and if so, you can delete
> sec_backup.gpg.
> 
> I think this should be safe, since you keep a backup of the local copy
> until you are sure the deletion didn't delete unintended stuff.

That is for sure a more elegant path :)

> HTH,
> 
> Peter.
>