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

Add SHA checksums and GPG fingerprints for client downloads #171

Open
tox-user opened this issue Nov 21, 2017 · 1 comment
Open

Add SHA checksums and GPG fingerprints for client downloads #171

tox-user opened this issue Nov 21, 2017 · 1 comment

Comments

@tox-user
Copy link
Contributor

It is weird that a program made for secure messaging doesn't have checksums and GPG fingerprints listed on its website. Currently if the site got hacked or if the files on it were replaced in a man in the middle attack the user won't be able to know. All of the clients should provide them.

@nurupo
Copy link
Member

nurupo commented Nov 22, 2017

Yeah, hashes and signatures are good, we should add them. Only Windows, macOS and static Linux downloads and currently unsigned though, all other downloads are signed. Well, ignoring the direct APK download, since you can F-Droid it and it's signed on there.

Out of the unsigned downloads, the macOS uTox and qTox downloads that link to GitHub releases and the uTox Windows download that links to uTox website are easy to add signatures for, we could just ask qTox and uTox teams to provide them.

As for other unsigned downloads, the qTox Windows downloads and static/semi-static Linux downloads, it's somewhat challenging to sign them as they are usually nightly builds that get build automatically on Jenkins. There are some issues with signing them that need to be solved. I will try looking into those, but I have little free time lately, so it might take a while.

Currently if the site got hacked or if the files on it were replaced in a man in the middle attack the user won't be able to know.

Btw, if someone does hack or somehow mitm the website (rogue CA?), nothing stops them from changing the hash and the signature information on it, so that hashes and signatures would perfectly match. The only way users would notice the hack is if they have previously added our signing key to their keyring, before the website was hacked, and they check the signature of the hacked binary agains that previously added key, not the new key which hackes have placed. I'm not arguing against signatures, signatures are a good security measure, I'm just explaining how would they help in your scenario.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants