brave / browser-laptop

[DEPRECATED] Please see https://github.com/brave/brave-browser for the current version of Brave
https://www.brave.com
Other
7.94k stars 975 forks source link

Publish code signing keys and signatures #197

Closed diracdeltas closed 6 years ago

diracdeltas commented 8 years ago

We should publish our code signing keys and signatures so that anyone can independently verify them. See https://www.torproject.org/docs/verifying-signatures.html.en for an example of a project that does this.

I also think it's a good idea to sign git tags.

dconnolly commented 8 years ago

:+1:

bbondy commented 8 years ago

Great idea, CC @aekeus

aekeus commented 8 years ago

Agreed and build out a page like https://www.torproject.org/docs/signing-keys.html.en

luixxiul commented 8 years ago

+1 from support

gripedthumbtacks commented 8 years ago

Yes! :)

alexwykoff commented 8 years ago

+1 from support https://linkbubble.zendesk.com/agent/tickets/5307

jonathancross commented 7 years ago

Thanks for getting this started @diracdeltas, this is important for security and verifiability (Brave is not just a browser, but also a Bitcoin wallet).

Any progress on this effort?

I looked for GPG keys of the top 10 Brave contributors and only found keys for you and @luixxiul (5879E688C4ECE35D), unfortunately. At the very least, it would be great to have @bbondy sign the releases.

PS: Would also be great to have SHA256 checksum of each binary.

bbondy commented 7 years ago

@jonathancross you can find my info here: https://keybase.io/bbondy

I think @posix4e is going to be working on this by the way.

jonathancross commented 7 years ago

Thanks @bbondy, would be fantastic if you and / or the next release engineer started signing releases so we know you actually created them. Anything blocking you from doing this?

You can then upload your public key to GitHub so users see a green "Verified" next to the release. Of course I get that this is not essential and should not be trusted alone, but it gives users one more way to quickly verify integrity of releases.

Ideally the dev team should also sign each other's keys.

I think @posix4e is going to be working on this by the way.

I did find 0x55B6A41A4273E82B for @posix4e. Is Alex going to become the release engineer in the future?

bbondy commented 7 years ago

I added my public key to github recently and set the git option to auto sign, I'm not sure if that will auto sign the tags/releases or not but I'll see on my next CI build script run. Posix is helping with Linux packaging.

srirambv commented 7 years ago

+1 on SHA Checksum from community https://community.brave.com/t/sha256-checksum-for-binaries/1926

jonathancross commented 7 years ago

@bsclifton is now creating releases and signing some (with key 0x37FF5F19022427F2), but not the last few unfortunatly. More than half of the commits recently are signed, so we're making progress :-)

bsclifton commented 7 years ago

For this issue, we could start off by just having the checksums available. It might also be great to have a page showing verified contributors (and their keys)

We can also display how to check if the executable is signed:

Many of us are signing our commits (which is great) but the version bump commit is not signed (it happens in an automated build). Also merge commits are not signed

diracdeltas commented 7 years ago

I think commit signing solves the issue of whether the source code is legit, but IIUC this issue is for verifying if the pre-built binaries on brave.com are legit. Most users are running the binaries, not checking out commits. Unfortunately we don't yet have a reproducible build process.

A page like https://www.torproject.org/docs/signing-keys.html.en that lists the keys used to sign the various releases would suffice

jonathancross commented 7 years ago

https://www.torproject.org/docs/signing-keys.html.en that lists the keys used to sign the various releases would suffice...

This is a good start, but it is only useful because the devs sign their commits and every binary release is also signed. Doesn't help much if devs are not signing releases.

diracdeltas commented 7 years ago

@jonathancross i believe @bsclifton's comment above indicates the releases distributed from brave.com (which is where most people download Brave) are signed. but yes, ideally we would sign the ones posted on Github as well.

jonathancross commented 7 years ago

@diracdeltas Ah, yes, "signed" can mean different things. I was referring to standalone GPG signature files specifically.

On torproject.org, users have a convenient link to a gpg signature for each binary. Doesn't matter much where the signatures themselves are stored (github or brave.com).

bsclifton commented 7 years ago

+1 from @DarkCoridor via https://github.com/brave/browser-laptop/issues/10601

I am unable to find the fingerprint of the various PGP signing keys you use to sign Linux packages. Thus there is no way to know if the key you downloading at:

https://s3-us-west-2.amazonaws.com/brave-apt/keys.asc

Is actually the key meant to be there. Any malicious party with access to the AWS infrastructure could swap out malicious code and sign that with a fake key and it would seem "secure" to an end user.

posix4e commented 7 years ago

It's probably time to roll out new keys for the next release anyway. Let's make sure that it all gets published next time.

LilChange commented 6 years ago

Any progress? It seems you have had a new release. Exciting progress on DApps and all 😸 but how hard is it to post the fingerprints of your signing keys somewhere?

posix4e commented 6 years ago

Oh crap I will make sure this gets done. Thanks @LilChange

diracdeltas commented 6 years ago

@posix4e are you still taking this?

posix4e commented 6 years ago

@diracdeltas You should take it ( I thought you already did)

diracdeltas commented 6 years ago

Linux signing keys are live! https://brave.com/signing-keys

still need mac and windows

if someone on linux could verify that they can download, gpg import, and verify their builds using these keys that'd be great

thanks @jonathansampson for succeeding where many others have failed

gripedthumbtacks commented 6 years ago

@diracdeltas tested in a debian stretch docker, works fine. but fyi the "staging" versions are behind the standard release versions. 0.19.20 is in staging which is a bit older

$ apt-cache policy brave 
brave:
  Installed: 0.19.88-1
  Candidate: 0.19.88-1
  Version table:
 *** 0.19.88-1 500
        500 https://s3-us-west-2.amazonaws.com/brave-apt stretch/main amd64 Packages
        100 /var/lib/dpkg/status
     0.19.20-1 500
        500 https://s3-us-west-2.amazonaws.com/brave-apt-staging stretch/main amd64 Packages
diracdeltas commented 6 years ago

^ @bbondy @bsclifton @posix4e looks like brave-apt-staging needs an update? or is it deprecated?

bsclifton commented 6 years ago

@DtpEJsaYXDU4GDH8dE4MyI9VrieF0UZpPZ0K76K great catch- we just recently (last week) merged code for true release channels. After doing that, I published a new Beta... but neglected to update our Linux staging repo 😄

I'm attempting to do a publish now- please bear with me here

bsclifton commented 6 years ago

@DtpEJsaYXDU4GDH8dE4MyI9VrieF0UZpPZ0K76K OK the staging repo is now updated 😄

Would you mind checking again?

gripedthumbtacks commented 6 years ago

@bsclifton not seeing anything there now for staging

diracdeltas commented 6 years ago

update on publishing signing keys: Clifton sent me PEMs for the mac and windows signing keys, but I'm having a hard time validating them. i tried parsing them with openssl and keytool to no avail.

bsclifton commented 6 years ago

@diracdeltas both keys should be ~encrypted~ signed with my PGP key: https://keybase.io/bsclifton/pgp_keys.asc?fingerprint=d16c7e228bb0a9571f70605737ff5f19022427f2

diracdeltas commented 6 years ago

@bsclifton they were signed, not encrypted, and i already verified the signature. the problem is in the key format, not your signature of it.

bsclifton commented 6 years ago

@DtpEJsaYXDU4GDH8dE4MyI9VrieF0UZpPZ0K76K RE: some of the above- staging has been updated- the binary there is called brave-beta (not brave). We just updated the docs today here: https://github.com/brave/browser-laptop/blob/master/docs/linuxInstall.md#debian-jessie-and-ubuntu-artful-zesty-yakkety-xenial-and-trusty-amd64

gripedthumbtacks commented 6 years ago

The brave-beta package worked fine after enabling linux namespaces in my test environment

# echo 1 > /proc/sys/kernel/unprivileged_userns_clone

jonathancross commented 6 years ago

FYI: I'm seeing many signed commits with key 4AEE18F83AFDEB23, unfortunatly that key is owned and controlled by GitHub, so it doesn't really improve the situation.

evq commented 6 years ago

@jonathancross those signed with GitHub's key should be limited to merge commits created by using the GitHub web UI to merge PRs. I think the only way to personally sign the merge commits is by performing the merge manually and pushing the result to master.

foederati commented 6 years ago

Hi all, had been meaning to give Brave a try for a long while now. Was disappointed to not see any PGP signatures on the release files... found this issue opened in Jan 2016(?) but still no process together? To clarify, if I want to today download Brave 0.20.29.dmg, there is no PGP signature or even a SHA256 hash I can verify against the file I download?

RicardoCapricciosa commented 6 years ago

Same for me. I'd love to try Brave, but given that it's security and privacy aware and also a wallet I really want to be able to check the download against checksums and/or GnuPG keys.

bsclifton commented 6 years ago

As we transition from browser-laptop over to brave-core, we'll want to revisit this discussion

Closing this in favor of https://github.com/brave/brave-browser/issues/837