Error with key?

[sintrenton]

my log id: 0797dd5025a3145f7108781c

The site documentation gives no clue how to wrk with keys, when I try to log in through CLI, I get
ERROR Bad key found: no private key material or GPGKey
Logging in through web site works.
I see my key, ABCDEF1234567890 with "edit" next to it. Edit allows me to upload a new public key (it is updated elsewhere). FPR is unchanged. I provide my keybase passphrase.
Error: No signing key found

OK, so I don't have one, only a public key that was uploaded when I created this account long ago?
That must have worked once upon a time since I have verified myself on Twitter, Github, Bitcoin, Reddit, etc? Or do you not need to sign when verifying yourself on these?

So, how do I handle private keys on the website? Or signing keys? Or upload private keys, though I really am not too keen on that, no offense? The documentation gives no guidance whatsoever, and I find no link, no button, no menu choice that give me any clue how to proceed.

On my "personal page", I have a button "Action required":
Install Keybase (files waiting from xxxxx [unknown person])
Reset your keys & start from scratch
Edit your account/settings

I have installed the Keybase app three times now, no difference.
Start from scratch: I rather ditch keybase.io (while a good idea), and go back to clean PGP that I have used for almost 20 years.
Edit settings:
Change password: No thanks
Devices: If you install Keybase on any computers, those installs will show up here.
No device shown, restarted PC 4 times
the other three; not relevant, for the moment.

[yelper]

I'm having similar issues in #5804 when trying to log in without keybase explicitly storing my pgp private key. Also finding the documentation around the scenario very scant, which seems strange for a typical scenario (not allowing third-party server to have my private key).

[maxtaco]

@sintrenton seems like you hit a bug. Interfacing with GPG across all platforms and across all versions of GPG and across all types of keys has proven immensely onerous for a small company like ours, but also affects very few people, since we have most of the common cases working. Something about your case isn't common but it remains to be seen what that is.

@yelper can you provide a log via keybase log send.

[yelper]

@maxtaco logs are referenced in #5804: b23652b39bdf569374b5c11c

[maxtaco]

@sintrenton try this:

keybase db nuke
keybase login

Maybe that might work.

[sintrenton]

@maxtaco No, but I think I found the problem, when I got the error message.

I wasn't aware of that the keybase app looks for my private key on this machine
The thing is, I run GnuPG 1.4.21 -- I don't need the "fancy stuff" -- in a "portable mode" from inside a VeraCrypt volume file, meaning that keybase can not "find the corresponding private key on this machine".
My solution is probably that I will probably create a fork of my key, with subkeys specially for keybase.io use, while keeping my "main" key with subkeys in my volume file.
It should work creating a fork with the same main key ID, only different subkeys and password, I think?

If you have any other suggestions, feel free to comment here.

I'll post after testing and see how it goes.

[sintrenton]

Well that's partially solved.
I installed GnuPG 2.1.18 exe, with a forked key. Tested to encrypt to myself, sign, verify, etc, all worked.

I managed to log in with keybase, then got the following
Your keybase username or email address: me@mail.info
In order to authorize this installation, keybase needs to sign this installation
with your GPG secret key [secret key ID].
You have two options.

(1) Keybase can use GPG commands to sign the installation.
(2) Keybase can export your secret key from GPG and save it to keybase's local encrypted keyring. This way, it can be used in 'keybase pgp sign' and 'keybase pgp decrypt'
going forward.
Which do you prefer?: 1 / 2
Enter a public name for this device: [entered something]

I tried both options, both gave me the same reply.

- ERROR bad signature: Can't find a key for [my S subkey ID]: No keys match the given key IDs (error 1002)

Created a new log that may clarify: d9a077329ece599aae79bc1c

[bartmcleod]

Same issue here. Still not solved apparently. Is keybase dead?

[yelper]

@bartmcleod fwiw, the thread in #5804 helped me get moving again.

[bartmcleod]

@yelper Which parts exactly, there is quite a lot in there. What triggers me is that I had an old command line version installed and I wouldn't even know how to uninstall it.

[akater]

I get 1002 too. Older GnuPG software (which is really the only one people should be using) sometimes produces buggy keys when extending expiry dates (something that probably nobody should ever be using). That could be the reason behind this. GnuPG versions in question are <2.1. The bug won't be fixed in older versions of gnupg upstream. There is a request to backport the fix. See also discussion in OpenKeychain issues and a short report in OpenKeychain FAQ. Same or related bug is https://dev.gnupg.org/T1396

It also could have something to do with subkeys (which, again, probably nobody should ever be using).

[maxtaco]

@akater we'd need some more info to debug it. Maybe a keybase log send from the CLI if you're using that, or more info about the error message if you're just posting via CURL. GPG is extremely challenging to support, and we try to support all of the common cases, but it's a fractal that has infinitely many corners, so we're never going to get to 100%.

[akater]

It could be that my key with extended expired date did not propagate to keybase. Or maybe I did not even reupload the extended-expiry-date key to public keyservers until today (this looks unlikely). Anyway, the message is not very specific in that it does not mention that there's a matching key with expired date:

Error in your post
-------------------

Code: 1002
Name: SIG_CANNOT_VERIFY
Description: bad signature: Can't find a key for b2beb161b1ec7f44: No keys match the given key IDs

Here,
b2beb161b1ec7f44 is a signing subkey. Last time I interacted with the keybase, I did not yet extend the expiry date on my key.

I'm not going to use subkeys in the future and believe it was my mistake to use them (or expiry dates) initially. It introduces lots of complexity while benefits are hard to evaluate and might be non-existent.

[dhess]

I also created a Keybase account in the early days using my own "legacy" PGP key, and I had this problem, too, when trying to use the Keybase app. Here is what I did to fix it. The Keybase app on my Mac is now fully functional, and I have since successfully linked the iOS Keybase app on my iPhone to my Keybase account, as well.

I'm not sure exactly which step(s) resolved the issue as I did them all at once, but each of them is easy enough to perform. Note that my PGP key has multiple subkeys with expirations, plus several different email addresses, to boot.

1. The email address I used to register with Keybase was not one of the email addresses associated with my PGP key. I added that email address to my key; see https://www.katescomment.com/how-to-add-additional-email-addresses-to-your-gpg-identity/ for a helpful guide on how to do that.

2. I published my updated PGP public key to the MIT PGP keyserver.

3. From the keybase.io web interface, I updated my PGP public key. As I was not logged into the Keybase app at this point, I uploaded my new PGP public key to Keybase using the very long curl command that the web interface helpfully provided.

4. I ran keybase db nuke on my Mac.

5. I ran keybase login on my Mac. When prompted for my username or email address, I used the email address associated with my Keybase account (the same email address that I added to my PGP key in step 1).

6. When asked whether to have PGP manage the key signing for the Keybase app, or to import the PGP key into the Keybase app DB, I chose to import the key into the Keybase app DB. My thinking here was that if Keybase is managing it, there's less to go wrong.

After a few seconds, the keybase login command informed me that I was successfully logged in.