Establishing trust in keybase itself and its binary releases
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
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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