Client: Wrong "No matching keys found" on export

[soullivaneuh]

On a new computer (nexy), I tried to import my main GPG key like that:

❯ keybase pgp export -q 04460cd228df9e0d42f07643992eb6fafd4e6361 --secret
▶ ERROR No matching keys found

As you can see, it does not work. But I can still download the private key from the keybase.io app and import it manually. It makes no sense to me, what is the issue?

Plus, it seems I still can't use it directly, for exemple for passwordstore:

❯ pass path/to/auth
gpg: decryption failed: No secret key

But the needed key is here:

sec   rsa4096 2019-03-06 [SC]
      04460CD228DF9E0D42F07643992EB6FAFD4E6361
uid           [ unknown] Sullivan Senechal <[email protected]>
uid           [ unknown] Sullivan Senechal <[email protected]>
ssb   rsa2048 2019-03-06 [E] [expires: 2027-03-04]
ssb   rsa2048 2019-03-06 [SA] [expires: 2027-03-04]

FYI: All works for the other key.

[maxtaco]

Please keybase log send . CC @zapu

[soullivaneuh]

@maxtaco Here it is: 6b770312cc9ce6a2500b521c.

[soullivaneuh]

So I finally removed my second key and then did:

keybase pgp export | gpg --import
keybase pgp export --secret | gpg --import

It works and "solve" my problem.

If you don't find any issue from my log, feel free to close this one. :+1:

[zapu]

Sorry, no clue what went wrong here. The log does not reach that far back to show the failures you've experienced. I also tried this on a fresh account with different combinations of keys and could import/export successfully.

[QimatLuo]

Got the same issue. my log id: 05cd7600b630fad82befcb1c

[kanutope]

I have got the same issue on my 'older' first installation. Can't find a trace of a 'second key'.

Executing 'keybase pgp export -s' and comparing the 'keybase.service.log' files on both installation, I find a difference:

old computer/installation (▶ ERROR No matching keys found)

skb_keyring.go:123] 60fa + Loading SKB keyring: . . ./Keybase/secretkeys.pawawa.mpack
skb_keyring.go:181] 60fc | Indexed 2 secret keys

new computer/installation

skb_keyring.go:123] 8bdc + Loading SKB keyring: . . ./Keybase/secretkeys.pawawa.mpack
skb_keyring.go:181] 8bde | Indexed 3 secret keys

[zapu]

Hey @kanutope thank you for reaching out to us.

Was the key in question imported into Keybase using the keybase.io website or keybase pgp import --push-secret? Can you send the logs (using keybase log send) immediately after using the command on both "old computer" and "new computer" and pasting log IDs here? Thank you.

[kanutope]

Hey @zapu thanks for your swift reply :-)

• pgp key was (re)created on the 'NEW' installation.
• I have repeated the pgp export -s, on both NEW (successful) and OLD (failing) installation.
• log sent (NEW): 77d27f6eafaece1ae5c60f1c .
• log sent (OLD): da3e7e25bef99eca2a7f601c .

Cheers!

[maxtaco]

I am pretty sure this is the expected behavior. The pgp private key isn’t server synced.

[zapu]

So there are two keychains available for every Keybase user: one that is local, and one that stores keys on Keybase server, encrypted with user passphrase. If you only synced / imported to local keychain on machine 'NEW' (when generating it), it will not be automatically available on other machines.

[maxtaco]

Try keybase pgp push-private and keybase pgp pull-private

[kanutope]

Hi @maxtaco
I did keybase pgp push-private on NEW and keybase pgp pull-private on OLD.
private/.keys/pgp created successfully after 'push'.
With 'pull', ran into '▶ ERROR GPG error: exit status 2'.
Made keybase log send => a1a28b061ec8820fa4c58a1c .
I am investigating the server.log file - there might be something wrong with my GnuPG installation.

[kanutope]

Looking into keybase.server.log file, I saw /usr/local/bin/gpg --no-tty --import was failing.
I went to .../private/.keys/pgp, and tried 'manual' import gpg --import < <key>.asc, and that one succeeded, after requesting for my passphrase.

[maxtaco]

If our small company were 10x the size we could accommodate every breaking change of every minor version of gpg on every platform under every package manager. But alas.

[kanutope]

hi @maxtaco - I don't know whether it has to do with the gpg version. I checked again, and the 'manual' import succeeded thanks to the GPG_TTY variable being set (independently of the --no-tty option.
Thanks for your support. Cheers!
Just a last observation: I've gotten my secret PGP key transferred to the OLD machine, though the keybase pgp export -s still returns the "No matching keys found" error.

[kanutope]

• solved *

Revoking the OLD machine and scratching the entire Keybase user data did not resolve the issue.

Though, got it working after reading through https://github.com/keybase/keybase-issues/issues/2793 and performing
gpg --export-secret-key 1A9342D586065111 | keybase pgp import --push-secret.
Message returned:
▶ INFO Key 01018488fbae49e539f76f2f198d252bac7223ca8cdd2b8bef51cd1d364962c039930a already exists. Only importing the private key.

[mattouille]

Let me be the first to say, there is something absolutely wrong here.

Log ID: a6f0f31d67eccd8373ae641c

I tried importing my key several times and it works non-deterministically.

~  97  21:19:38  ✔  keybase pgp export -q 36DF664C07A67A08 --secret | gpg --allow-secret-key-import
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
▶ ERROR No matching keys found
gpg: processing message failed: Unknown system error
~  98  21:21:39  ↵ 2|2  keybase pgp export -q 36DF664C07A67A08 --secret | gpg --allow-secret-key
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
▶ ERROR No matching keys found
gpg: processing message failed: Unknown system error
~  99  21:21:46  ↵ 2|2  keybase pgp export -q 36DF664C07A67A08 --secret | gpg --allow-secret-key --import
gpg: key 36DF664C07A67A08: "Matt Ouille <[email protected]>" not changed
gpg: key 36DF664C07A67A08/36DF664C07A67A08: error sending to agent: Inappropriate ioctl for device
gpg: error building skey array: Inappropriate ioctl for device
gpg: Total number processed: 1
gpg:              unchanged: 1
gpg:       secret keys read: 1
~  100  21:22:16  ↵ 0|2  export GPG_TTY=$(tty)
~  101  21:22:39  ✔  vim ~/.zshenv
~  102  21:22:54  ✔  keybase pgp export -q 36DF664C07A67A08 --secret | gpg --allow-secret-key --import
▶ ERROR No matching keys found
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
~  103  21:23:00  ↵ 2|2  keybase pgp export -q 36DF664C07A67A08 --secret | gpg --allow-secret-key --import
▶ ERROR No matching keys found
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
~  103  21:23:03  ↵ 2|2  keybase pgp export -q 36DF664C07A67A08 --secret | gpg --allow-secret-key --import
▶ ERROR No matching keys found
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
~  103  21:23:04  ↵ 2|2  keybase pgp export -q 36DF664C07A67A08 --secret | gpg --allow-secret-key --import
~  103  21:23:12  ↵ 2|2  keybase pgp export -q 36DF664C07A67A08 --secret | gpg --allow-secret-key --import
▶ ERROR No matching keys found
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
~  103  21:23:14  ↵ 2|2  keybase pgp export -q 36DF664C07A67A08 --secret | gpg --allow-secret-key --import
▶ ERROR No matching keys found
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
~  103  21:23:16  ↵ 2|2  keybase pgp export -q 36DF664C07A67A08 --secret | gpg --allow-secret-key --import
▶ ERROR No matching keys found
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
~  103  21:23:17  ↵ 2|2  keybase pgp export -q 36DF664C07A67A08 --secret | gpg --allow-secret-key --import
▶ ERROR No matching keys found
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
~  103  21:23:18  ↵ 2|2  keybase pgp export -q 36DF664C07A67A08 --secret | gpg --allow-secret-key --import
gpg: key 36DF664C07A67A08: "Matt Ouille <[email protected]>" not changed
gpg: key 36DF664C07A67A08: secret key imported
gpg: Total number processed: 1
gpg:              unchanged: 1
gpg:       secret keys read: 1
gpg:   secret keys imported: 1
~  103  21:23:46  ✔  keybase log send

[zapu]

That seems similar to a bug in pgp decrypt that we have fixed previously. I'll take a look, thank you.

[maxtaco]

could also be a local pinentry/gpg misconfigure

i hate to ask for this @mattouille, but will do so anyway. please have some sympathy for us, gpg is basically impossible to support, given it breaks with every minor version and that every combination of platform, package manager and dotfiles provides additional bugs and misconfigurations, and demands further workarounds.

[maxtaco]

(...also as @zapu says, there is a bug that we've recently fixed....)

[mattouille]

@maxtaco I definitely have empathy for your situation and I apologize if I came off like I didn't.

Some context
I use Keybase to manage my PGP key which signs all of my commits for work and another which signs my personal commits. Keybase has basically become an integral part of my development process both professionally and personally.

Yesterday my hard drive failed and I ended up having to rebuild my OS, which means going through the process of exporting my keys from Keybase. Normally this process is very smooth and predictable and I spent the better part of an hour messing with it before I figured out it was failing non-deterministically.

I'm not frustrated with Keybase, you all, or anything of the sort - just the scenario I was in. That's the frustrated tone you're reading.

I still love Keybase and I'm thankful every day for you all maintaining it.

I left off the most important part of all: I use Keybase PGP because I _don't_ like dealing with GPG.

[maxtaco]

Understood, thanks @mattouille for the clarification! Hopefully the next build solves the issue in general. But for now, is the workaround of trying n times good enough for you to recover your important data?

BTW, I currently use keybase pgp push-private to sync my PGP private keys via KBFS. This would be useful in the case of a disk crash.

[mattouille]

Interesting. I guess I had always looked at my desktop GPG provided pgp keys as "temporary" (or as long as this OS install lasts) and I was treating my Keybase generated ones as empirical.

Also, yes, once it's installed I don't need to mess with it and it eventually succeeded.