Open grant-olson opened 5 years ago
After trying to restart the app, I go back to the main screen, and am allowed to enter my username, but the button to click after I enter it is greyed out and has a spinning wheel.
Can you run keybase log send
and we'll take a look at the logs? Thanks. Sorry about the snafu.
Sent and received a log id of c726ce1c3637d32842c4e31c
I tried rebooting my machine. The software is installed but I'm not logged in and attempting to do so has the same problem.
Can you try keybase login
from the terminal btw?
I tried that. It a little surprisingly popped up a GUI window to enter my password. I entered it and that brought the main login screen with spinning wheels to the foreground. And now it's hanging again. I close the app and get a big red ERROR EOF
on the CLI login and finally get returned to a shell prompt.
I then closed the main app and tried the CLI login again and get this error:
master-blaster:~ grant$ keybase login
Keybase isn't running. To start, you can run:
open /Applications/Keybase.app
▶ ERROR There were multiple errors: dial unix /Users/grant/Library/Group Containers/keybase/Library/Caches/Keybase/keybased.sock: connect: no such file or directory; dial unix /Users/grant/Library/Caches/Keybase/keybased.sock: connect: no such file or directory
master-blaster:~ grant$
I ran the command to restart the app which popped up the big normal app window again, but DID NOT login, and retried keybase login
from the CLI. Once again get the dialog for password. And currently back to software hanging in the CLI.
From the logs it looks like Keybase runs this gpg2 command which hangs. Please try running this command and report whether it hangs and what is output. If you'd rather keep the output private feel free to encrypt it for max.
/usr/local/bin/gpg2 --no-tty --with-colons --fingerprint -K
Are you using a yubikey or anything like that? Something that could stall gpg waiting for interaction.
Do you have other gpg
/ gpg2
binaries around?
which -a gpg gpg2
There was a stray lock file from when I first tried running the app on July 19th.
(p3env) master-blaster:factor grant$ /usr/local/bin/gpg2 --no-tty --with-colons --fingerprint -K
gpg: checking the trustdb
gpg: waiting for lock (held by 1184) ...
gpg: waiting for lock (held by 1184) ...
gpg: waiting for lock (held by 1184) ...
(p3env) master-blaster:factor grant$ ls -al ~/.gnupg/*.lock
-rw------- 2 grant staff 43 Jul 19 11:48 /Users/grant/.gnupg/pubring.gpg.lock
-rw------- 2 grant staff 43 Jul 19 11:48 /Users/grant/.gnupg/secring.gpg.lock
I'm currently trying again but it seems something is taking some serious time. I'll see if I can wait it out and was just impatient before or if the keybase process dies.
The issue is that I'm a victim of the poisoned keys that have been published to the keyservers:
https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
I suggest since you don't care about the WoT for keybase, you add --no-auto-check-trustdb
to any shell commands you're running. The following command completes successfully:
p3env) master-blaster:factor grant$ /usr/local/bin/gpg2 --no-auto-check-trustdb --no-tty --with-colons --fingerprint -K
gpg: please do a --check-trustdb
sec::2048:1:B6F6FFD0E3B5806F:1263195573:1420311664::::::::#:
fpr:::::::::A530C31CD7620D26E2BAC384B6F6FFD0E3B5806F:
uid:::::::798ADF585D18360DD1489D633F3CC5269CDEF610::Grant T. Olson (Grant - home email) <olsongt@verizon.net>:
uid:::::::46849505EF502ADCAA1ADF4D14568D54E82E68D9::Grant T. Olson (Personal email) <kgo@grant-olson.net>:
uid:::::::BF16B5CD3FD40AE6E3EFF6BA261855FC09AFF584::Grant T. Olson (pikimal) <grant@pikimal.com>:
ssb::2048:1:1458BCCB6A8F7CF6:1263195573::::::::::
ssb::2048:1:FE45E55DA18A54D6:1267481952::::::::::
ssb::2048:1:5C9FE6DFD53982CE:1283291728::::::::::
Thanks, we'll look into it!
Thanks, we'll try adding --no-auto-check-trustdb
.
Do you have a copy of the poisoned key that I can play with? Downloading a handful of rjh keys from Berkeley on a machine with gpg 1.4.20 and gpg2 2.1.11 didn't seem to elicit the hang.
In the meantime to get into your account, do either of these mitigations work?
Open GPGPreferences and uncheck "Auto-retrieve keys" (from a support forum)
Comment out the keyserver
line from ~/.gnupg/gpg.conf
(from that gist)
Simpler than 1 or 2, this may work
keybase --gpg-options="--no-auto-check-trustdb" login grantolson
The first batch of workarounds didn't work, but I effectively did the same thing as that last one by adding no-auto-check-trustdb
to ~/.gnupg/gpg.cong
After that I run in to another problem which may be related to keybase/keybase-io#1771 which was closed as a feature not a bug. I have tried re-uploading my key with updated expiration dates through the web interface but even after that have problems with an expired key:
master-blaster:grant-olson.github.io grant$ keybase login
Your keybase username: grantolson
▶ WARNING Skipping expired primary key (A530 C31C D762 0D26 E2BA C384 B6F6 FFD0 E3B5 806F)
▶ ERROR Sorry, your account is already established with a PGP public key, but this
utility cannot find the corresponding private key on this machine.
This is the fingerprint of the PGP key in your account:
A530 C31C D762 0D26 E2BA C384 B6F6 FFD0 E3B5 806F
You need to prove you're you. We suggest one of the following:
- put one of the PGP private keys listed above on this machine and try again
- reset your account and start fresh: https://keybase.io/#account-reset
I'll dig more in to that and open another issue if needed.
Er... keybase/keybase-issues#1771
The key I have is 30 megs so I can't upload it in github. Also seemingly too big to send via keybase encrypt. To see if you do have the poisoned key try gpg --armor --export B44427C7
and then see if the size is 30 some meg? Trying to find some way to get the key to you without leaving more poison out there on the internet.
You can also try forcing the keyserver to the pool as not all installs do this by default. gpg --keyserver pool.sks-keyservers.net --search-keys ...
Hey @grant-olson
this log line:
▶ WARNING Skipping expired primary key (A530 C31C D762 0D26 E2BA C384 B6F6 FFD0 E3B5 806F)
seems to indicate that the key is still expired in your GPG keyring. Keybase shells out to gpg
to figure out what PGP keys are in the keyring and useable during login process.
Is it possible that you have non-standard GPG_HOME
or other settings, but Keybase picks up some old key from default keyring?
All I can say is if I use the gpg listed in above comment where I was asked to run /usr/local/bin/gpg2 --no-tty --with-colons --fingerprint -K
I can sign and verify without any issue:
master-blaster:arduino_flashforth grant$ /usr/local/bin/gpg2 --no-tty --with-colons --fingerprint -K
gpg: please do a --check-trustdb
sec::2048:1:B6F6FFD0E3B5806F:1263195573:1420311664::::::::#:
fpr:::::::::A530C31CD7620D26E2BAC384B6F6FFD0E3B5806F:
uid:::::::798ADF585D18360DD1489D633F3CC5269CDEF610::Grant T. Olson (Grant - home email) <olsongt@verizon.net>:
uid:::::::46849505EF502ADCAA1ADF4D14568D54E82E68D9::Grant T. Olson (Personal email) <kgo@grant-olson.net>:
uid:::::::BF16B5CD3FD40AE6E3EFF6BA261855FC09AFF584::Grant T. Olson (pikimal) <grant@pikimal.com>:
ssb::2048:1:1458BCCB6A8F7CF6:1263195573::::::::::
ssb::2048:1:FE45E55DA18A54D6:1267481952::::::::::
ssb::2048:1:5C9FE6DFD53982CE:1283291728::::::::::
master-blaster:arduino_flashforth grant$ echo foo | /usr/local/bin/gpg2 --armor --sign | /usr/local/bin/gpg2 --verify
You need a passphrase to unlock the secret key for
user: "Grant T. Olson (Personal email) <kgo@grant-olson.net>"
2048-bit RSA key, ID A18A54D6, created 2010-03-01 (main key ID E3B5806F)
gpg: Signature made Thu Sep 5 10:36:39 2019 EDT using RSA key ID A18A54D6
gpg: please do a --check-trustdb
gpg: Good signature from "Grant T. Olson (Personal email) <kgo@grant-olson.net>" [ultimate]
gpg: aka "Grant T. Olson (pikimal) <grant@pikimal.com>" [ultimate]
gpg: aka "Grant T Olson <grant@webkite.com>" [ultimate]
If I post-date my clock I can't sign:
master-blaster:arduino_flashforth grant$ date
Fri Jan 10 10:39:41 EST 2020
master-blaster:arduino_flashforth grant$ echo foo | /usr/local/bin/gpg2 --armor --sign | /usr/local/bin/gpg2 --verify
gpg: no default secret key: Unusable secret key
gpg: signing failed: Unusable secret key
gpg: verify signatures failed: Unknown system error
master-blaster:arduino_flashforth grant$
This is what led me to believe the expired key was server-side, not on my box.
Can you try to quit Keybase completely and then try standalone mode to sign up? The command would be keybase --standalone login
. Sometimes it helps because it inherits all of current environment, including all GPG stuff that might affect how it works.
I checked your public key in your public Keybase profile and it's not expired. So now it is the case of making Keybase shell out to gpg correctly.
That had the same error. Then I tried adding -log-file log.log
to see if I could see the exact gpg command. After that the program runs and terminates without listing any errors, but doesn't actually complete login. This happens both with and without --standalone
You can get it to print entire log by doing keybase -d --standalone login
.
You can try to force it to use /usr/local/bin/gpg2
by doing keybase --gpg=/usr/local/bin/gpg2 --standalone login
I opened a new issue regarding the expired key. I believe the fix for the current issue is the fix I listed above.
Thanks. The fix for the current issue, using --no-auto-check-trustdb
, will be in the next release.
I'm trying to install the app for the first time after having an account for years. The app hangs indefinitely after I enter my password and I need to kill it.
From the website, I did get this message: "You chose to manage your PGP private key yourself (nice!), and you don't have any Keybase devices yet." that indicates I'll need to sign something manually to bootstrap the initial install. I'm not sure if this is affecting the install or is unrelated, but mentioning it since I'm probably traveling down some less tested code paths.