keybase / node-client

CLI for keybase.io written in/for Node.js

node-client

END OF LIFE WARNING

This Keybase app is no longer supported. Active development continues elsewhere.

Upgrade to our new client via our download page.

Issue tracking & reporting

The keybase-issues repo is a consolidated issue repo for the whole project. We'll organize and tag issues there.

node-client's Issues

Key verification failing: subkey checked rather than primary key

taco1: bad key: B707AD86 != 96D307BE

This only happens after we've signed a key for inclusion into our keyring. Before inclusion, it spits out the full PGP fingerprint, which is actually better!

Can't imagine revoking is working properly...

Since @km seems to be uninitialized.

Sigchains aren't updating properly

If we download a new link from the server, we never update the parent user object, so it just keeps refreshing again and again.

The solution is simply to update the parent user object when adding chainlinks.

Use `--with-colons` when parsing the output of GPG query commands

Rather than hack-parsing the human-readable output. This is probably the much more robust solution.

Strip out `log` code and use our new `iced-logger` module

This can wait, but eventually, seems like a good idea.

Cleanup crashed key imports on every startup

Check the sqlite3 DB and delete keys accordingly.

`key_selector` doesn't respect `--homedir`

Not sure what the plan of attack should be, but for now it's breaking regression testing for #16.

Regtest problem: they are incredibly slow

Maybe we should have a way to pick up halfway through. The slowest thing so far is signing up, and proving, and waiting for github/twitter, etc. Slow slow.

keybase verify feature

Probably need to factor out a lot of decrypt

Totally broken on Linux

Sometimes we don't get anything from stdout from gpg. Works fine on Mac but it's fucked on linux. keybase version is fucking broken.

Single key keyring concept

Chris's idea to keep keys used for verifying in a temporary single-use keyring. That way we don't have to worry about conflicts. It is nice idea but demands a big refactoring. Maybe leave it for Now.

Regtest problem: 2_ doesn't work, there are two problems at least:

1. We're getting that horrible don't trust this key message. I am not sure why not, but we don't have this problem with the live client, so it's likely something having to do with temporary keys.
2. We're still not properly decrypting, I think there's a prompt that we're missing, but unable to really understand due to the previous issue.

handle usernames in signup that have issues

Some issues include:

1. taken by someone else
2. are invalid (since they contain a curse)
3. are invalid since are not long or short enough, have unfriendly characters, etc.

Client reports that tracking is up-to-date, but I'm not so sure...

Look into it!

Errors tracking locally - looking up identities without proofs

These errors on my machine.

This user has a twitter proof but not a github proof:

chris vangogh ~/git/keybase/keybase/sql >keybase track chris
warn: Missing track in signature
warn: Missing track in signature
warn: Missing track in signature
warn: Missing track in signature
info: Signature is already revoked: 263bedf900d6e8a2a430bb92b98f3c1ea1fab4e391b1abb9e0caa37264def8ed0f
info: Signature is already revoked: df33e3d366a9f30cb28a413c77b9b4b8900f1a227dae610f4b20204901f561830f
...checking identity proofs
✔ "kbtester1" on twitter: https://twitter.com/kbtester1/status/417699763287379969

/Users/chris/opt/node/lib/node_modules/keybase/node_modules/keybase-proofs/lib/scrapers/github.js:125
      return api_url.indexOf("https://gist.github.com/" + username + "/") ===

and then when we tried to track chris1000, who has a key but no proofs:

keybase track chris1000
...checking identity proofs

/Users/chris/opt/node/lib/node_modules/keybase/node_modules/keybase-proofs/lib/scrapers/twitter.js:99
      return api_url.indexOf("https://twitter.com/" + username + "/") === 0;
                     ^
TypeError: Cannot call method 'indexOf' of null
    at TwitterScraper.exports.TwitterScraper.TwitterScraper._check_api_url (/Users/chris/opt/node/lib/node_modules/keybase/node_modules/keybase-proofs/lib/scrapers/twitter.js:99:22)
    at TwitterScraper.BaseScraper.validate (/Users/chris/opt/node/lib/node_modules/keybase/node_modules/keybase-proofs/lib/scrapers/base.js:34:17)
    at /Users/chris/opt/node/lib/node_modules/keybase/lib/sigchain.js:450:31
    at ok (/Users/chris/opt/node/lib/node_modules/keybase/lib/sigchain.js:465:23)
    at Deferrals.runtime.Deferrals.Deferrals._call (/Users/chris/opt/node/lib/node_modules/iced-coffee-script/lib/coffee-script/iced.js:115:18)
    at /Users/chris/opt/node/lib/node_modules/iced-coffee-script/lib/coffee-script/iced.js:127:26
    at Object.runtime.trampoline (/Users/chris/opt/node/lib/node_modules/iced-coffee-script/lib/coffee-script/iced.js:94:16)
    at Deferrals.runtime.Deferrals.Deferrals._fulfill (/Users/chris/opt/node/lib/node_modules/iced-coffee-script/lib/coffee-script/iced.js:126:26)
    at iced.Deferrals.parent (/Users/chris/opt/node/lib/node_modules/keybase/lib/sigchain.js:442:38)
    at ok (/Users/chris/opt/node/lib/node_modules/keybase/lib/sigchain.js:443:21)

Factor out tracking into a library so that all subcommands can use it.

yippee!

Shouldn't allow untracking if not tracked

Right now we'll blindly allow it

BaseSigGen should write new links to local storage after successful upload...

Since we obviously don't need to pull from the server what we've written ourselves.

Imports on decrypt and verify should go into a sequestered keyring

Right now, they're being imported into the main keyring. We might take the stance that keys are allowed in the main keyring that aren't trusted, but I think that's kind of ugly.

This might need to be solved, if at all, along with issue #29. Alternatively, there could be an obscure GPG option that I'm missing.

Include version # with the client in the HTTP headers

Better `revoke` interactivity

Maybe fetch the primary key, and then ask whether it in particular needs to be revoked or not.

Deep Race Condition in Client-Side State and `api_urls`

Here is the sequence to consider:

1. User A generates a github proof
2. User B runs keybase track/id A and sees a failure
3. User A posts the gist to gist
4. User B runs keybase track/id A and still sees a failure

The problem is that chain links aren't strictly speaking immutable. They can change when the proofd process goes through and checks them. We can take the position that the client should do what proofd is doing. But it's nice to have all of that scraping happening on the server. The other alternative is for the client to update chain links for those with dead api_urls. Once the api_url is filled in, it shouldn't change.

This is a really annoying bug that's going to take some time to fix, unfortunately.

Why does the temporary keyring wind up being suffixed with `~`?

I'm not sure who's doing that, is it GPG?

Regtest problem: github is rate-limiting us

And that slows things down every further.

Running `track --local` twice in a row will naively import and sign the target key

We can probably be smart about not doing anything much in the case of the key already being in our keyring and signed, and skip the whole key import and signing process.

Untracking is broken

Don't get the right behavior if you untrack and then retrack. I think compression is broken.

Cleanup: fingerprint in `user.iced`

With @fingerprint and @get_fingerprint(). It's quite ugly, let's clean it up.

Allow for github auth

...for users who make a lot of requests. The logged-out limit is 60/minute.

Better error message needed if you try to verify when you should be decrypting

Right now, we just get a GPG failure and no further explanation.

Even if we can skip remote checks, we should still print out what they are

...So maybe still want to run check_remote_proofs

when reregistering need to clean out DB

Or maybe repartition the DB so that it can handle multple users?

Reg test for encryption / decryption / verify / sign

Regression: seems like local tracking stopping working...

We're checking every time now it seems, even on repeated keybase track --localss. I thought we didn't need to check the remote proofs in that case?

Explore using a temporary keyring for *their* keys

Need some work on this.

Need to be smarter about resigning imported keys

First of all, if the key is already imported and signed, then we shouldn't resign it, since it will prompt the user for a password.

Second of all, we probably want to ask the user if he's ok with it, before signing the key? Maybe we're already doing that with approval of remote proofs.

`encrypt` is maybe overeager when it comes to tracking

maybe it should be less so.

Cleanup: uppercase v. lowercase PGP key fingerprints

Ideally we could stick with one, or at the very least, need to be more explicit as to which is being used.

Horrible PGP warning on `keybase encrypt`

max@somme ~/s/keybase-node-client (master) [8]> make; and ./bin/main.js encrypt -m "hi" taco1
node_modules/.bin/iced -I browserify -c -o `dirname lib/command/encrypt.js` src/command/encrypt.iced
date > build-stamp
warn: Tracking was already revoked for e09d91b0fd45b7da6de3d5783b77d200 (ignoring untrack)
warn: Tracking was already revoked for e09d91b0fd45b7da6de3d5783b77d200 (ignoring untrack)
warn: Tracking was already revoked for e09d91b0fd45b7da6de3d5783b77d200 (ignoring untrack)
...checking identity proofs
✔ "tacovontaco" on twitter: https://twitter.com/tacovontaco/status/414116418955669504
✔ "tacoplusplus" on github: 
Permnanently track this user, and write proof to server? [Y/n] n
warn: gpg: B707AD86: There is no assurance this key belongs to the named user

pub  1024R/B707AD86 2013-12-17 keybase.io/taco1 (v0.0.1) <[email protected]>
 Primary key fingerprint: C3A1 EE10 4C35 A518 B660  9502 5308 C23E 96D3 07BE
      Subkey fingerprint: B51A 5F3E 91DF 7124 2537  04E5 5F86 64C8 B707 AD86

It is NOT certain that the key belongs to the person named
in the user ID.  If you *really* know what you are doing,
you may answer the next question with yes.

Use this key anyway? (y/N) y
-----BEGIN PGP MESSAGE----- 
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

hIwDX4ZkyLcHrYYBA/0fycbCVNIhYRes336v+2/WnQtIrfCbROYCzrzaQPVDCUNK
HaH+TD2S9sR+4UbWLaoOh8I4sQAbJT/2iljNLePxCxRJpQ1Ga7rXpSHu8lUSm7yX
zFgS9JVJxqKoINAxIUI21VQuBkpC9UHph9MY+t8S3EE8+a953Rx4oawy31ANFNI3
AcGD1GyAto4cPxmd+dVrRYFP6wqwVplUyWWyeakv78NU86WEpQdCZp9+vQ0FI2FH
/NAGVJcd8Q==
=iIJH
-----END PGP MESSAGE-----

Decrypt fails if client not in english

since we're scraping output. I'm not sure of how best to solve this

`db.open` should be in the base class..

And subclasses should say whether or not they want it...

Don't trust the standard C/As, make our own

http://www.freebsdmadeeasy.com/tutorials/freebsd/create-a-ca-with-openssl.php

Looks like we'll have to create a CA. Eventually the options we need are traced back to here:

http://nodejs.org/api/tls.html#tls_tls_connect_options_callback

Seems like the 'cert' option is just for client certificates. Seems like the ca option
is the only way to distribute the server public key.

The configuration setup gets horribly confused once we log in as a different user

Some possible solutions:

1. Have the logged in user ID as a column in each table.
2. Have the DB named after the logged in user. This has the disadvantage that state isn't stored across the two users, but maybe that's OK.

Implement a `keybase switch` feature

Which is the agreed upon way to change users.

Also, a keybase logout might be useful.

Make a `pull` feature to pull a secret key from the server

Will need 3sec to decrypt, of course.

Make a `status` feature

Will list:

1. Logged in as
2. Session active/non-active
3. Private key available/non-available

Others?

Figure out software upgrades

...Especially for scrapars

Use `--keyid-format long` for all output

Rather than the short mofos. This is going to be extremely useful and protect against all sorts of collision attacks that we're now open to. Stil, I'm not stoked about the 64-bit target space, it might be the fundamental weakness of the system.

Refactor `iced-utils` and `pgp-utils`

Move all of the iced-generic stuff like athrow and bufeq_secure from the latter to the former.

`keybase revoke` fails if you try to revoke without a key pushed

Need a reg test here.

Regression Test Suite!

End-to-end regression testing. We need to figure out how to make PGP keys in batch mode to make this possible. Or potentially, we can you KBPGP to do so, just for testing.