gpg2 --edit-key "Need the secret key to do this."
Open, NormalPublic


Trying to adduid to an existing key fails:-

$ gpg2 --edit-key "Someone"

Secret subkeys are available.

pub  rsa4096/0701B5FD88888888
     created: 2013-02-20  expires: never       usage: SC  
     trust: unknown       validity: unknown
ssb  rsa4096/48D4E49499999999
     created: 2013-02-20  expires: never       usage: E   
ssb  rsa4096/4825BF8CCCCCCCC
     created: 2013-02-20  expires: never       usage: S   
[ unknown] (1). SOmeone <none@spambucket>

gpg> adduid
Need the secret key to do this.

toggle gives the same error message.

Searching for similar problems, I see many such reports without any clear solution.
The old Privacy handbook seems to be too old to help and the man pages simply leave too many terms undefined, and do not address such problems.

I am unclear whether the difference between "Secret *subkeys* are available,
and "Secret *keys* are available" is significant.

gpg-connect-agent with keyinfo --list only displays the public keys.

gpg2 does decrypt properly, prompting for the passphrase and thus obviously accessing the
secret key (or is that gpg-agent?).

The only unusal thing might be that GNUPGHOME is pointing away from ~/.gnupg .
This is in a Debian testing environment.


gpg (GnuPG) 2.2.12, libgcrypt 1.8.4
Wanderer created this task.Mar 9 2019, 6:16 PM

I should have added, in case it wasn't obvious, that I changed some ids etc in the report just to protect precise details.

werner added a subscriber: werner.Mar 10 2019, 2:43 PM

You are keeping your primary secret key offline. You need the primary secret key for most operations because it is required to bind user ids or new subkeys to the primary key. The "pub" indicates that you have only the public part of the primary key. There are several howtos on how to move a key offline and you seem to have followed on of them. The common advise is to have a designated box with the full key (including the primary key) and use that for key maintenance. Of course you can also import the primary secret key.

Thanks for the prompt reply. I did not explicitly move the primary key offline. Maybe there is something in the default debian configuration that does that?
$GNUPGHOME is pointing to a .gnupg which contains secring.gpg and also a directory private-keys-v1.d/ which contains two keys.

I clearly need to read some more documentation, although that is where I get lost. There seems to be no clear way to find anything that is not referring to the old gpg which does not seem to match what I see with gpg2. Maybe I need to look at the source.

Meanwhile I discovered rfc4880 which seems to define many of the unexplained terms in the man pages. I suggest that the man pages should refer to that RFC under the SEE ALSO section.

Just to note that I did import the secret key, but there was no change. I have searched for the term designated box, but I found no hits. Where is this term defined or explained?

Sorry to present what are presumably trivial questions well known in the community, but I need to know where to look.

Thanks for your help, and work in gpg.

Despite my previous denial, I now think that you are correct: I now think that I did indeed follow a Debian wiki entry on separating the primary key. In my defense it was many years ago :-(. I have now managed to import a primary key, although unfortunately the wrong one.

Perhaps I should now close this bug report, although the lack of documentation including the inadequate man pages made it extremely hard to discover what was wrong. Or even interpret the information displayed by gpg2.

I have just seen that there is a git repository for a revised gnu privacy handbook, so perhaps the new version will throw more light on all of this.

Again, thanks for the help and your patience.

What terms in the man page are troublesome for you?

(I wrote "designated box" as a shortcut for a non-networked computer which is used solely for operations with the primary key, sometimes people call this CA laptop)

OK. Designated box wasn't a technical term, so obvious in retrospect.

In passing, I have now recovered the missing secret key which I had hidden very effectively.

Now that man page... I fear that it is going to take a lot of work to analyse all the problems that I had/still have. One problem is as I have been reading widely around gpg, some of the issues have been resolved, so I may not remember all of the difficulties that I had coming back to it for some more unusual options. I say coming back, because I had a reasonable understandiing some years ago, so I was not completely new.

Obviously, first and foremost, it is far too long. A man page is just unsuitable as the primary documentation for a complex package. I know that isn't very helpful, and in the absence of anything better, I am not suggesting that it be shorter.

Let me take a problem I had earlier today: gpg2 --import args. The man page does not explain what arguments are expected, at least not where it is needed. Looking at --export, it looked as if it would probably accept a file of some sort. And it worked with one I tried.

Another issue is that the section on "HOW TO SPECIFY A USER ID" needs to be flagged up earlier in the man page. And then it is unclear. For example, By key ID:-
"This format is .. of the string..." What string? I can guess, but it assumes too much.

I know, documentation is an absolute pain. And I wish I could volunteer to help. Maybe the new Privacy handbook will fix many of these problems.

The man page also needs to be updated (or reference) whats-new-in-2.1 ,especially the New format for key listings. The "missing" KeyIDs in the listing is extremely confusing to someone used to the old system. I wasted much time trying to discover what I was missing.

werner triaged this task as Normal priority.Mar 19 2019, 1:42 PM
werner edited projects, added Documentation, gnupg; removed Bug Report.