keybase / keybase/client

Establishing trust in keybase itself and its binary releases

Open
#8,298 5 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Go
Stars
9.2k
Forks
1.3k
Avg merge
12h 58m
Merged PRs (30d)
56

Description

Please make it clearer, more robust and easier for a person who is new to keybase to establish their own trust in your keys and code. This is the crucial initial bootstrapping problem.

One requirement is ensuring that users don't have to trust your website, and their connection to it, completely as of the moment they try to install things. Because, of course, web sites are pretty easy to hack, and it is pretty easy to fool people about what they see on the web.

E.g. at Keybase - our public code-signing key I see just a few links of unclear helpfulness.

Simply once again telling us, from your own web site, that your key fingerprint is 222B 85B0 F90B E2D2 4CFE B93F 4748 4E50 656D 16C7 doesn't help with this bootstrapping of trust.

If you show people how to list the signatures on that key: gpg --list-sigs 656d16c7 (they may need to import it first?), and then looking for trust in those keys is one approach. One way to facilitate that would be providing a link to PGP key statistics : Chris Coyne - chris.at.chriscoyne.com which allows folks to trace paths of trust to one of the signers of the keybase key from some other key they trust (hopefully their own...). The other signing keys don't seem to be in the strong set which is necessary for use of that tool.

Another good approach would be to make it obvious how users can check keybase's own announcements of its own key and identity on a variety of other web sites and key repositories. Showing how to do that would provide a good introduction to the whole keybase security model, and demonstrate how it doesn't rely on trusting the keybase code itself.

Including an explanation of how to use gpg to get from the keys at https://keybase.io/.well-known/keybase.txt to keybase's own code-signing key would be a good start.

Beyond that it seems suspicious that I see nothing relevant e.g. at https://gist.github.com/keybase/ or https://twitter.com/search?q=%40keybaseio%20verifying%20myself&src=typd
If there is a good reason for not announcing your own key there, please document it.

Other good approaches would be to link to publications of your key via dnssec (or even plain old dns) providing some sort of useful tie from the X.509 certificate world, and demonstrating compliance with HTTP Public Key Pinning and HTTP Strict Transport Security.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the linked Keybase public code-signing-key page and the .well-known/keybase.txt entry, then review the proposed GPG signature-listing and external-announcement checks. Done should provide a clear, robust way for new users to independently verify Keybase keys and binary releases without relying solely on the website.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
cryptography, documentation, security
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.