maxtaco
commented
9 years ago Seems to work fine now in both the CLI and the Web site. We've had a lot of trouble with the HN API giving inconsistent or slow updates. Might that account for your woes?
Closed karanlyons closed 9 years ago
maxtaco
commented
9 years ago Seems to work fine now in both the CLI and the Web site. We've had a lot of trouble with the HN API giving inconsistent or slow updates. Might that account for your woes?
maxtaco
commented
9 years ago (But btw this error message is buggy, which is an issue I haven't seen before).
karanlyons
commented
9 years ago Perhaps this is just an issue with my machine, then? I’m running keybase 0.7.7 with gpg 2.0.26 and node 0.10.36. I’m not sure what other dependencies there are.
Again, this only seems to happen with my account (at least, that I’ve found). iding you, for example, works completely fine (✔ "maxtaco" on hackernews: https://news.ycombinator.com/user?id=maxtaco).
Manually piping the signature into keybase decrypt works just fine, and manually hashing that signature (base64.b64encode(hashlib.sha256(base64.b64decode(sig)).digest())) matches the proof_text_check in my HN bio. The only difference is the lack of padding in the latter, but I assume that’s accounted for and intentional: for example, your proof_text_check also lacks padding, and the CLI has no issues with it.
I think the issue resides somewhere in the initial fetching of data from the HN api.
karanlyons
commented
9 years ago Okay, I’ve figured it out!
The hackernews _check_api_url function is returning an error, because api_url does not match @api_url(username). For example (apologies for the scrolling):
| Keybase User | api_url |
@api_url(username) |
_check_api_url(api_url, username) |
|---|---|---|---|
max |
https://hacker-news.firebaseio.com/v0/user/maxtaco/about.json |
https://hacker-news.firebaseio.com/v0/user/maxtaco/about.json |
true |
karanlyons |
https://news.ycombinator.com/user?id=karanlyons |
https://hacker-news.firebaseio.com/v0/user/karanlyons/about.json |
false |
Here’s what I think is happening: My proof was generated before you got access to the firebase API for HN, so it’s designed for the old style scraping. However, the keybase client no longer supports that version of validation. So we fail at the first step of checking that the URL I signed(?) matches the URL the client expects.
Firstly, I’d say that error message could be improved by at least noting that the issue is that the expected URL and the signed(?) URL do not match.
Secondly, the client should really support both methods of validation (old school site scraping in addition to the API) if it’s not possible to automatically use the new API. I’m not sure how easy that is to mesh with the BaseScraper class.
Finally, I can obviously (I think) just revoke and reprove my HN account. I don’t know how many other users would need to do this as well, and you obviously (I hope) can’t automatically reprove them with the new API, but you could shoot out an email to the subset of users with the older proof version letting them know they should revoke and reprove themselves. Or, and I might be wrong about this, if the actual API URL isn’t signed it might just be a quick update in keybase’s database.
@maxtaco: Shall I keep my old proof around to help you test things out, and/or is there anything more I can do to help? I just barely understand the source code for the CLI so I’m not really comfortable issuing a pull request there, and it really seems like just notifying the affected users or updating the URL (if possible) would be the kindest solution both in terms of simplicity for the CLI and kindness to HN’s servers.
karanlyons
commented
9 years ago Okay, further inspection seems to show that just altering _check_api_url in hackernews.iced so that it returns whether or not api_url matches either @api_url(username) or @human_url(username) fixed the problem, but it was a hack.
What I couldn’t understand was where that incorrect api_url was coming from. It’s not in the signed payload, it’s not in user/lookup.json, it’s not sig/get.json, and I honestly couldn’t think of another place to check.
The command line client has a cache. It was pulling stale data from there, and gaslighting me as a result. I had no idea that it did that. Manually clearing out ~/.keybase/keybase.idb fixed everything. I don’t honestly know if that counts as “fixed”, but I’m closing this issue and leaving the chain intact as a record of my personal insanity. In retrospect I should have realized there was a debug flag and used it: the debug logs make it very clear what was going on.
I guess my only question now is: How is cache invalidation handled by the command line client? Does it not handle the case of API responses changing independent of signatures/user data?
My HN account (13 karma) has the keybase proof string, as required:
[ my public key: https://keybase.io/karanlyons; my proof: https://keybase.io/karanlyons/sigs/AKcTFtVA5RkCb0y1ELulZGf8Iu-yZtYTbYYiwf1Bw3Q ]keybase.io correctly verifies the hash, but the CLI fails:
This doesn’t seem to be the case for some other keybase accounts I’ve tried, but I’m flummoxed as to what the difference between those accounts and mine are. Note that all other verifications for my identity succeed in both the web interface and CLI.