Total GPG Failure All 1.13.0 Downloads #4852
Comments
|
Where did you download them from? |
|
Just checked and verified the source from https://github.com/qTox/qTox/releases signatures for the source are correct. For macOS there are no signatures, since it's built on TravisCI and we can't verify the build process there. For the Windows installers I just pinged @tux3, because he does the Windows builds. |
|
Yeah, binaries fail. Source tarballs mostly help Linux/BSD. Average people d/l Windows or macOS binaries. Now, offering a secure end-to-end crypto tool that cannot d/l validate is, well, pretty darn goofy. Have a dev sign Travis builds by hand. I would assume somehow he'd d/l his latest build while logged into Travis over some TLS or ssh pipe.
https://github.com/qTox/qTox/releases/download/v1.13.0/qTox.dmg https://qtox-win.pkg.tox.chat/qtox/win64/download https://qtox-win.pkg.tox.chat/qtox/win64/download-sig https://qtox-win.pkg.tox.chat/qtox/win32/download https://qtox-win.pkg.tox.chat/qtox/win32/download-sig https://qtox-win.pkg.tox.chat/qtox/win64/download-portable https://qtox-win.pkg.tox.chat/qtox/win32/download-portable |
|
@nurupo mentioned there were some issues with signing those builds some time ago: Tox/tox.chat#171 |
|
Thanks, he's wrong in saying
Users can validate by public keyservers independent of any websites a la gpg --recv-keys 0x31039166FA902CA50D05D6085AF9F2E29107C727 0xC7A2552D0B250F983827742C133203A3AC399151 0xCA9221C5389B7C50AA5F779352A50775BE13DF17 0xDA262CC93C0E1E525AD21C8596775D454B8EBF44 0x2880C860D95C909D3DA45C687E086DD661263264 0xBA7883E22F9D35945BA3376053137C3033F09008 0xAED311349C23A123E5C4AA4B139CA0453DA2D773 Indeed GPG will tell them if they happen to have the keys on their keyrings already. Unless the hackers also compromise the public keyserv network everything will work as it should. These matters have been thought through many times in many places, there is a reason why Linux distros sign their packages with GPG nowadays. |
|
@nixitixin of course one could manually sign Travis builds, but that is still no guarantee Travis doesn't insert a backdoor (unlikely, but it's the cloud™). Also none of us runs macOS, so we can't even check if the binary does something suspicious. Windows builds should be signed though and I already notified the person who can do that. |
That issue I have mentioned in there has nothing to do with the issue being discussed here. |
I'm not wrong, you just misunderstood what I said. In my scenario users get those public keys from the hacked website, so the hackers modified the website replacing the valid public keys with their own, which are also available on public keyservers, so the users would run the |
|
Reproduced the verification failure |
|
I have found what the issue is.
Those stable binaries are supposed to be built only on releases and stay the same until a new release, but apparently there was a misconfiguration which caused qTox to be rebuilt every time someone pushed to qTox repository. In the image below you can see 3 builds done in December that shouldn't have been done.
In the image below you can see that it was caused by a push to to the qTox repository, which rebuilt the updater, which in turn caused the setup executable to be rebuilt.
Using the build from November 28th the verification succeeds: I will try to fix the rebuilding issue on Jenkins now by deleting the newer builds that shouldn't have happened (partially why I have made the screenshots of them, since they will be gone now), this should make the |
|
Should be fixed. The download links now point to the right qTox build. Just re-download the @tux3 I have removed the qTox updater from |
|
Thanks for fixing the problem quickly. The fix worked for me on Windows installer exe's. Starting with a fresh blank GPG keyring: $ gpg --recv-keys 0x31039166FA902CA50D05D6085AF9F2E29107C727 0xC7A2552D0B250F983827742C133203A3AC399151 0xCA9221C5389B7C50AA5F779352A50775BE13DF17 0xDA262CC93C0E1E525AD21C8596775D454B8EBF44 0x2880C860D95C909D3DA45C687E086DD661263264 0xBA7883E22F9D35945BA3376053137C3033F09008 0xAED311349C23A123E5C4AA4B139CA0453DA2D773 gpg: requesting key 9107C727 from hkp server keys.gnupg.net gpg: requesting key AC399151 from hkp server keys.gnupg.net gpg: requesting key BE13DF17 from hkp server keys.gnupg.net gpg: requesting key 4B8EBF44 from hkp server keys.gnupg.net gpg: requesting key 61263264 from hkp server keys.gnupg.net gpg: requesting key 33F09008 from hkp server keys.gnupg.net gpg: requesting key 3DA2D773 from hkp server keys.gnupg.net gpg: /XXXXXX/XXXXXXXXXX/.gnupg/trustdb.gpg: trustdb created gpg: key 9107C727: public key "Polshakov Dmitriy Vladimirovich " imported gpg: key AC399151: no valid user IDs gpg: this may be caused by a missing self-signature gpg: key BE13DF17: public key "Alexey Razinkov " imported gpg: key 4B8EBF44: public key "sudden6 " imported gpg: key 61263264: public key "tux3/mlkj " imported gpg: key 33F09008: public key "Zetok Zalbavar " imported gpg: key 3DA2D773: public key "qTox Team " imported gpg: no ultimately trusted keys found gpg: Total number processed: 7 gpg: w/o user IDs: 1 gpg: imported: 6 (RSA: 6) $ wget --trust-server-names --input-file=fetch.txt $ gpg --verify setup-qtox32-1.13.0.exe.asc gpg: assuming signed data in `setup-qtox32-1.13.0.exe' gpg: Signature made Tue Nov 28 14:02:09 2017 MST using RSA key ID 3DA2D773 gpg: Good signature from "qTox Team " gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: AED3 1134 9C23 A123 E5C4 AA4B 139C A045 3DA2 D773 $ gpg --verify setup-qtox64-1.13.0.exe.asc gpg: assuming signed data in `setup-qtox64-1.13.0.exe' gpg: Signature made Tue Nov 28 14:02:04 2017 MST using RSA key ID 3DA2D773 gpg: Good signature from "qTox Team " gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: AED3 1134 9C23 A123 E5C4 AA4B 139C A045 3DA2 D773 The Windows portable builds still have crazy filenames and lack sigs as does the macOS dmg file. On that security discussion, we're getting into weeds. Yes I grasped all variant scenarios implied by your remarks, and there are more than you think. Better men than us have thought them through. Ask why GPG is used to sign any binaries anywhere. It's not just a matter of uploading fake keys, a spoof website, and jiggered apps. There is a web of trust involved. And I don't just mean technical GPG trust sigs, but many eyes watching websites, never mind authors. As "the enemy" I'd just hack a dev with a 0-day and insert spoofed binaries from his home PC to the unmodified qTox website. Right now that's easy for unsigned binaries. Please worry about this immediate threat over some hypothetically possible GPG caper as complex as Ocean's Eleven. Harden the build chains, github passphrase entropies, network firewalls, and such like. I don't see crypto attack theory as in scope. We just need GPG sigs to work as on all other open-source projects. The perfect is the enemy of the good. Whether or not releases can be hacked, "make them work for it." It's possible to sign webpages, post sigs in side channels, etc. Many open-source project release announcements include sigs in the announcement e-mail. Thanks |
|
@sudden6 If Travis can insert a backdoor, can't GitHub do that too somehow? @nixitixin nobody is questioning the importance of GPG, but if I understood correctly those remaining builds will not be signed until the problem @nurupo mentioned in the issue I linked is resolved. Don't we need to know at least one person from the web of trust for it to work? We need to know someone who signed the key. Otherwise we won't know if the key from the keyserver wasn't uploaded by the attacker. |
They are not really portable builds, they are unstable "nightly" builds based on the latest development progress. Whenever someone pushes code change to qTox git repository, it builds a new "nightly" qTox. (I put nightly in quotes because the build is done not once per day overnight, but every single time someone pushes code, so it can be rebuilt multiple times a day or once a week). I have complained to qTox people a few times that they shouldn't be calling those "portable builds", that's misleading, not to mention that they still use system-wide qTox settings ( The nightly builds do lack signatures as we haven't developer any signing process for them. They were setup mainly for testing purposes rather than serious use, which is that the stable releases are for, so we were fine with having those unsigned. It would be nice to have them signed and it's something that I want eventually to do, but it's not very simple. The builds are automated, so the signing would have to be automated too, and if the website would link to the nightly builds (which it currently does), we might need to update the website every time a build is made as it's a static page website. In fact, the website would need to be updated through GitHub so that the source and the actual website stay in sync, meaning we'd need to setup a GitHub bot, etc. Alternatively, we could make the website a bit more dynamic. We also can't sign the nightlies on the build server directly due to some security concerns, so the nightlies would need to be automatically uploaded on some other signing server, meaning we'd need to develop some Jenkins plugin or write an inodewatch+rsync application in C... anyway, it's quite complicated and not a 5-minute task, if we do this we want to get it done right and not rush a half-complete solution. It's also a bit low priority as we have more important things and tings that require our immediate attention on our plate and we are quite undermanned at the moment to deal with everything. |
It can't if you sign your commits and releases, since it would invalidate the signatures. You could even sign your issue messages if you wanted to, just like you pgp sight email. In the worst case it can only deny addition of new commits/releases or providing (targeted?) users outdated commits/releases. |
|
Good clarifications. I'd remove nightlies from the main d/l page. Just footnote a link on it to some other page for nightly builds. Those aren't important to sign. Most developers compile from git anyway if they're doing nightly work like that. So the trust is basically placed on github. When Travis emits a final build, not much more need happen. A dev signs .exe's and .dmg's by hand and uploads .asc files. Automation isn't worth it. Releases happen every 6-8 weeks and signing is a 2-minute job. The .asc files needn't appear in the same web page as binaries, if that's hassle. URLs are URLs and can point anywhere from the main d/l page. Thanks |
|
How do you verify that the binary you got from Travis is what you want it to be? That it doesn't have a backdoor? |
|
Having reproducible builds is one way, it's a build property that makes the same source code result in the same bit-by-bit identical binary. Someone trusted could build it on their own macOS system and verify that the resulting binary is bit-by-bit identical to the one Travis has produced, meaning that Travis didn't backdoor it. Builds are not reproducible by default though, you need to put quite some effort to make them be reproducible. I'm also not sure if it's possible to do with macOS, as reproducible builds are generally made in a VM with specific compiler version, library version, user name, system time, etc. so there is a legal question of running a non-free OS like macOS in a VM. So given that qTox builds are not reproducible, and even if they were no one has a macOS system to check if Travis has modified the build, no one can verify the binaries from Travis, and without being able to verify you are left with the only choices of either blindly trusting or not trusting it. Similar applies to the Linux packages setup on the OBS. Our build server where the Windows qTox is built it a bit more trustworthy than Travis or OBS since @tux3 has full root access to it and he can exemine it whenever he wants. It's still not as good as having reproducible builds though. |
Previsouly addressed in closed issue #4095. Reproducible building is overkill right now. Someone just needs to sign .dmg's that Travis emits based on his trust in them, a better quality trust than ours, to stop MITM attacks if nothing else. A sig at least guarantees we're getting the binary .dmg that qTox devs expect us to get. Over-focus on nightlies is distracting from basics. Developers know their way around these matters, average users don't. Focus on average users. The nightly jazz also confuses web pages having both "portable" (so-called) and "nightly" (so-called) listings right next to stable official releases. That's not the way to offer apps to the public. Send developers elsewhere and keep things simple and straight for everyone else. Thanks |
1.13.0 binaries fail GPG checks.
macOS .dmg has no sig file. It can't be verified.
Windows installers (32 and 64) give BAD signature.
Windows "portable" downloads have no sig files (and crazy filenames too).
The text was updated successfully, but these errors were encountered: