Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upload the release-signing key to keybase.io #12730

Closed
mcdallas opened this issue Mar 19, 2018 · 7 comments
Closed

Upload the release-signing key to keybase.io #12730

mcdallas opened this issue Mar 19, 2018 · 7 comments

Comments

@mcdallas
Copy link

Might be a good idea to upload the release-signing key to keybase.

Keybase allows you to link github accounts/domains to a public key in a way that anyone can verify that the owner of the key is the owner of the repo/domain and you don't have to rely on the web of trust.

@eklitzke
Copy link
Contributor

and you don't have to rely on the web of trust.

So what would you be relying on instead?

@mcdallas
Copy link
Author

So what would you be relying on instead?

You can verify yourself that the owner of the key is the owner of the domain/github account by checking the signed proofs they posted in these accounts. You don't have to trust someone else to certify that the public key is owned by that person.

Example: I can be sure that the owner of that key is also the owner of gpgtools.org and GPGTools twitter account because they have posted said proofs here and here

@achow101
Copy link
Member

IMO keybase does not provide any usefulness for us regarding the release key. Signed proofs can be done without keybase, and the release key isn't even used on social media platforms so signed proofs for such accounts are pointless. Furthermore, the release key is not Wladimir's personal PGP key so it doesn't even have social media accounts to be associated with (such accounts should be associated with Wladimir's personal PGP key). The release key is used solely in releases which are published on a mailing list and for the signed hashes file. The fact that the release key has been used before to sign emails from Wladimir's email address is enough proof that he owns the private key.

@maflcko
Copy link
Member

maflcko commented Mar 22, 2018

Git commits and tags are signed, so you can already check that the fingerprint was signed by a bunch of people (including the maintainers of the project)

https://github.com/bitcoin/bitcoin/blame/185d48473e439743d68ede0208738f3a3e48bbce/contrib/verifybinaries/README.md#L10

@laanwj
Copy link
Member

laanwj commented Mar 27, 2018

Not sure about this. If people think this actually helps security, I'm willing to do it. But if it encourages a lazy way of working where users trust keybase.io instead of verifying, it would do the opposite.

@eklitzke
Copy link
Contributor

To be honest I'm not really sure how this would work. I put a GitHub attestation on my Keybase account last year, which you can see here: https://gist.github.com/eklitzke/abf27489e0020bd5ff8d75fe2b9465c4

The idea is you put up a gist, and then the gist is signed with information proving that you own the gist. That's proves that the person who has the key on keybase also owns that GitHub account. There isn't a bitcoin GitHub user account as far as I know. I don't think projects can upload gists, only users (correct me if I'm mistaken).

You could put up an attestation of the key on bitcoin-core.org but I'm not really sure how that's better than just putting the key itself on bitcoin-core.org.

@laanwj
Copy link
Member

laanwj commented May 8, 2020

I'm closing this. Keybase was acquired (or aqui-hired) by Zoom, it's unlikely to survive very long.

And apart from that this issue has been dormant for years.

@laanwj laanwj closed this as completed May 8, 2020
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Feb 15, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants