Trust Individuals

[docalb]

During set up there's a a part where it pops random people's (gnu keys? some sort of key?) on screen and asks if you trust them. How do I know if I can trust these people?

[BenWestgate]

Do you believe they've reviewed the Bitcoin source code and built it and then attested to the validity of release checksums and that they would not sign a release with security flaws, or that they did not review its changes or that they did not personally build from source to verify the release they signed matches the code they reviewed.

If not, you don't. But you can ask someone else who you trust who they would trust.

This is too wordy for a dialog box unfortunately.

[BenWestgate]

Most people should just click skip if they did not review Bails source code. How would you know it even does anything with the public keys you trust without looking at my code?

Ultimately you trust me or peeked at my code. So if you trusted just click skip. I will make that better my checking from a short list of people I trust.

Then remove the "highly" recommended from the text, because it will happen no matter what they hit, they just won't choose who's signatures to check if they click skip.

[BenWestgate]

“If you don’t know who to trust, the creators of Bails can choose for you.” Which, if I’m remembering correctly, is what happens if you click “skip” anyway.

[BenWestgate]

Skip button should be changed to "Let Bails Verify for me"

[BenWestgate]

Try to make use of: https://github.com/bitcoin/bitcoin/blob/master/contrib/verify-binaries/README.md

[BenWestgate]

@docalb: Proposed solution

Hardcode people we trust. Always check for these signatures. 2 Good Signatures allows clicking "Continue" instead of "additional verification". If they click additional verification anyways: Import keys from GitHub for the current release. Display only the people with Good signatures in the .asc file for the downloaded release, including the people we hard coded it may have already found good signatures for. Let them say if the trust or don't trust each individual shuffled.

To keep it simple, it can just loop through the shuffled list until 2+ good signatures are found AND a new good signature was added, or the list was exhausted.

Then return to the "continue" or "additional verification" dialog. Which should mention the number of good signatures the download has and who the trusted signers are.

Example: if they started with 2 good sigs from hardcoded individuals, they could reach 4 good sigs by clicking "additional verification" twice and trusting someone new each time.

If they clicked that but untrusted the existing good sigs it'd keep looping until they reached 2 trusted people.

And "Continue" would be insensitive (can't click it) with less than 2 good signatures, the only option would be "additional verification".

And the delays should be much faster because it won't be querying the keyserver for each signature's public key.

Technical details:

I could make a Gtk dialog that toggles the sensitivity based on the number of signatures. But it might be faster to code and superior UX to just have a zenity dialog explaining Why they have to find other signatures they trust. (We didn't find 2 good signatures).

[BenWestgate]

We are going to use the following trusted signers.

names_counts = [
    ('laanwj', 9), ('Emzy', 9), ('achow101', 9), ('benthecarman', 7), ('sipa', 3)
]

Bails will randomly select and import from bitcoin/guix.sigs, 3 of the above who signed the current release. Future releases will have a minimum threshold of 2 good signatures, allowing some of them to drop off occasionally without annoyance.

2 will also remain the minimum if someone does "additional verification and decides to not trust some of the 3 pre-trusted signers. Making that step less likely to loop unless they distrust 2+ of the 3.

After the keys are imported from guix.sigs, we will verify them against the openpgp.org hidden service key server to be sure none have been revoked. In order to be considered a good signature it will need to be on both the key server and the bitcoin/guix.sigs repo for redundancy.

Since the standard install already trusts github to deliver honest results (as in their copy of the bails source code) it makes sense to trust github again to deliver the keys.

however for a higher trust model the pubkeys will be part of this repo. So in a more complex install method where a signed package or tar.gz is involved our signatures can be checked essentially vouching for the correctness of public keys contained.