Open ShalbafZadeh opened 8 years ago
I would suggest sha256/sha512 if you want to confirm "package health and safety" as finding md5/sha1 collisions is quite easy afaik.
EDIT: Example of an MD5 collision: http://www.mscs.dal.ca/~selinger/md5collision/ EDIT 2: Example of an SHA1 collision: https://shattered.io/
Still relevant, I would like to see this.
Looks dev doesnt care about this (again)
Hey there!
This issue will be automatically closed in 7 days if there would be no activity. We therefore assume that the user has lost interest or resolved the problem on their own.
Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.
Thanks!
Still relevant.
Hey there!
This issue was inactive for a long time and will be automatically closed in 30 days if there isn't any further activity. We therefore assume that the user has lost interest or resolved the problem on their own.
Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.
Thanks!
This issue was inactive for a long time and will be automatically closed in 30 days if there isn't any further activity. We therefore assume that the user has lost interest or resolved the problem on their own.
Why do you even think that inactivity for any period is a reporter's guilt? This type of issue cannot be resolved on their own. That's up to a program author to publish hashes and signatures along with each release.
Hello everyone and happy weekend! I hope you are doing fine.
I'd like to know if you need any help on this. I have some years of open source background and I'd love to contribute to move forward with this request as I believe it is a big security feature that we should address.
Thanks!
I really don't think it's' a big deal thing to do, and on top of that it could be automated :) You could at least add a step in the build pipeline to print the hashes of the resulted file to be downloaded
This is completely bizarre to not have this implemented 6 years ago when requested. What's the deal?
Can I be clear on this issue! Is there still no way to verify the integrity of the app download, in my case tsetup.4.10.3.tar.xz for Linux? I find this extremely difficult to believe, considering the nature of this application. Unfortunately, I'm forced to suspect that that this is a conscious decision on the part of Telegram and their partners, and that there is a hidden agenda guiding this policy. Unless somebody can convince me that my suspicions are false, I will not be installing Telegram on my PC. I hope I'm wrong!
Can I be clear on this issue! Is there still no way to verify the integrity of the app download, in my case tsetup.4.10.3.tar.xz for Linux? I find this extremely difficult to believe, considering the nature of this application. Unfortunately, I'm forced to suspect that that this is a conscious decision on the part of Telegram and their partners, and that there is a hidden agenda guiding this policy. Unless somebody can convince me that my suspicions are false, I will not be installing Telegram on my PC. I hope I'm wrong!
if you don't trust the binaries you can compile yourself.
Yes, I understand that, but but I'm not a programmer and I cannot audit the code myself. Does the source code come with an integrity verification facility, such as SHA256/512 checksum? Please provide a link to the details.
"...we strongly recommend using only Secret Chats in official or at least verifiable open-source apps for sensitive information... - Telegram FAQ (https://telegram.org/faq#q-can-telegram-protect-me-against-everything) A privilege only available to mobile app users as Secret Chats are unavailable on desktop apps (Linux in my experience).
And I think that we must ask the question: If Telegram and their partners don't see the importance of this simple but essential security measure, could the introduction of it at this late stage be trusted?
@Bobuntuu How does this work? I'm unfamiliar. So, I deploy my binary release to https://desktop.telegram.org, files are on https://td.telegram.org, I show the SHA checksums on the same page, on https://desktop.telegram.org?
If somebody compromises downloading from https://td.telegram.org and inject his malicious binary, how can he not inject SHA of this malicious binary on the https://desktop.telegram.org?
Hi, Where is published the SHA checksum for the Telegram.dmg file, offered as a download to MacOS users?
@Golffies Where should it be published?
Hi John,
It seems to me that the checksums are often published on the same page as the download page. For us users, this is the most obvious place to find them. But the choice is of course up to the application publisher. For example, Mozilla makes the checksums for all Firefox installers available in a single text file on its website.
I hope I've understood the meaning of your question.
A picture is worth 1,000 words, so here's an example of what sometimes gets done.
@Golffies looks bad tbh. Can you tell me, what's the point of providing them there, if the webpage is served from the same domain with the same TLS certificate? If someone has access and can inject an invalid binary in this download link he can also inject a corrected webpage with checksums of that invalid binary.
@Golffies I just don't understand the meaning of providing them. What are they provided for?
Bump? Can't believe it's been 7 years already since OP, and I've also posted a message offering to collaborate back on April 2021 hehe.
Any progress?
@john-preston , I assume you alredy know what they are for based on your messages here.
I have two reasons that I can think of now:
Cheers!
PS if anyone from the maintainer's / developer's team is reading this: I still volunteer to contribute. If you're using pipelines nowadays to build it and publish it, it'd be as simple as adding a step inside a job of it.
@igeek88 But if the website wasn't compromised then you just download the binary. If you want a checksum, for any reason, you can count it. What's the point of on-site checksum if the website wasn't compromised? What's the point if the website was compromised and binary was replaced together with the checksum?
Point taken @john-preston , still the question related to why would certain companies do it anyway remains.
@igeek88 Well, I ask the exact same question. Anyone knows why they do that?
@john-preston Because they sign their checksums, the internet archives the checksums, people can verify checksums fetched from different places, different internet connections etc. This greatly increases the attack surface needed to compromise you and your team, and builds trust that people get what they think they're getting, and verify over time when things have changed. IE if someone MITMs your website, there are still other channels of trust and verification.
This oversight seems particularly eregious, and the only thing that would restore trust at this point is a 3rd party audit of the application. How do you skip this detail? It's literally just md5sum <the binary>
, copy, paste into html. Or sign it first, for extra points.
@john-preston I just downloaded the same version, tsetup.4.14.9.tar.xz
, on 2 consecutive days and got 2 different hashes. This deeply compromises trust.
edit: 3 different times, Something screwy is happening:
tsetup.4.14.9.tar.xz
, fetched yesterday: md5sum
is one thingtsetup.4.14.9.tar.xz
, fetched today: md5sum
is differenttsetup.4.14.9.tar.xz
, fetched again minutes later: md5sum
is same as yesterdaysYou asked:
Well, I ask the exact same question. Anyone knows why they do that?
This is why, it builds trust if you do it right.
Keep a single file with hashes of different versions, add all different versions' hashes in the same file, sign it, make your signing keys available, use proper semantic versioning which you appear to be cargo culting (on account of the hashes changing), let us know why you seem to be manipulating the versions, post the checksums on github so there's a separate channel than your domain, where people can keep a git history of version changes.
This makes it harder for an adversary to manipulate things, and it let's us know that that there's a greater burden on you, that you can't go back an rewrite history.
@john-preston I agree with what @freckletonj is saying:
Please post on github a signed file of sha512 hashes for all the binary versions distributed. Duplicate the file on telegram.org. It is really important that people can verify the authenticity of the binary distributions on all platforms. Posting a signed updated file of all checksums of all versions on two different websites (telegram.org AND github) goes a long way to address concerns of authenticity, with a historical record saved that way as well. Other people such as @igeek88 have offered to help with automation etc.
Telegram is trying to be safe and secure. How can hashes and signatures not be a priority?
What do you mean by a signed file? How do I sign it and with what?
What do you mean by a signed file? How do I sign it and with what?
John, we're expecting a bit of seriousness from you. You know exactly what he mean. Stop taking the piss. Regards.
@john-preston The point behind publishing the checksum is that to verify that when we download the file, on-route, nobody intercepted the connection and altered the file somehow. And even if the website was compromised you could publish the checksum on Github, 2 sources are highly unlikely to be compromised. And even if both are compromised you can even sign the checksum itself with your private key and we can verify it by using your public key. You can also check how Powershell core guys do it. 🙂
@Golffies Well, I really don't know. I have a pair of private / public keys for the auto updates signing, with public keys available here:
https://github.com/telegramdesktop/tdesktop/blob/dev/Telegram/SourceFiles/config.h#L50-L64
Maybe I could use those to sign also a text file with the setup digests together with computing them in the same script that uploads builds to GitHub, but I have no idea how this is usually done in the community, my autoupdate sign / check routine is in C++ and handcrafted, so it won't apply nicely here.
So be calm and respectful, thx.
@john-preston. This sounds very promising. I like this scheme with signing. I have some comments , too:
a. it looks like those RSA keys you use are only 128 bits? This might be a good time to upgrade to some strong keys, say 2048 bits
b. I think it is important that hash/checksum files contains a history of all the hashes/checksum of all the versions, at least starting from when the scheme is initiated.
c. Just wanted to mention in case people do not know : there is already a scheme for verifying downloaded apk against source code, as described in https://core.telegram.org/reproducible-builds I have never done this, not enough of an expert, but sounds like a great feature that will work in tandem with having official apk checksums available.
d. I just realized that this whole discussion is about telegram-desktop and the distribution and checksums thereof. What about apk verifiability via checksum, who would be in charge of that?
Very much looking forward to seeing secure (signed) publication of checksums of all binary formats distributed, whether for desktop or cellphones.
Thanks
@reikred I still didn't receive any response in regards to how usually checksum are signed with a private key, like what tools / algorithms are usually used for that so that anyone could check those signatures using the provided public keys.
Please Add Telegram Desktop package md5 or sha1 hashes in download page so users can verify package health and safety
[@stek29] gpg or sha256 would be better #2700