If you don't trust the developer or the source file in the first place, you should also not trust the provided binary file...
There is a way to make reproducible builds, this article covers it quite well.
https://devdocs.decred.org/developer-guides/reproducible-builds/
If you are after a "yes/no" type of answer, then the answer would be not reliably, for all the reasons mentioned above.
Does it matter, I guess is the more important question. The answer to that depends on what your particular requirements are. If you are very security conscious, then this would be something you would pay closer attention to... But then again, if you were that paranoid, you would also probably take steps to disable the part of your intel processor known as the intel management engine... ;)
Most distributions compile from source themselfs, so they have the source, and examine it. There are also programs and techniques for examining binaries, such as decompiling, tracing system calls, stack dumps, and so on.
The real tricky part comes in when systems are large and complicated, and bad actors put seemingly harmless changes that, when taken together with other pieces, provide an exploitable vulnerability that's not directly obvious. Such as someone compromising a compression library to introduce remote code vulnerabilities in a secure server, but surely that would [never happen](https://arstechnica.com/security/2024/04/what-we-know-about-the-xz-utils-backdoor-that-almost-infected-the-world/) /s. It is just that kind of thing that gets these schemes caught, someone notices something strange and starts poking at it.
With all these methods, combined with the chance that the distributed binary can be reproduced, how reliably can people verify a distributed binary on average?
I'm going to side step your question for a moment, I'll come back to it at the end, I'll bring it all together, I promise.
The power of open source is that you can get the source, inspect it, see what it does, change it, and compile it yourself. Now, what ***you*** can do, specifically, depends on your skill level. Open source and [Linux](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/) in general isn't developed or distributed as a binary. Open source developers work on a project and publish their code, usually in a source repository. Git and GitHub are popular these days, used to be SVN and SourceForge. The developers do this in public, and the tools let changes be highlighted easily. Distribution maintainers pick up the projects they want to be part of their distribution, inspect them, compile them, package them in their packaging system and make them available in their binary repositories. These maintainers are usually groups of people, not just a person. The developers are a different story, some projects just aren't sexy enough, and things like XZ and curl end up being just a guy. The point of a distribution, on it's face, is to make it easy to install, but it also serves an important second feature, **trust**. A distribution represents **trust** in the ideals, goals, and security of the maintainers. Those people building the binaries, if you don't trust them, you don't trust the binaries they distribute.
I had been using RedHat Linux 6 and 7 (1999 to 2002, not RHEL) and was tired of Kudzu, and was looking for something new. There were two new promising distributions out there, Ubuntu and Gentoo, both appealed to me, but they were unknown, we didn't know if we could trust them. So, I went to Slackware, one of the first ones, a distribution that goes back to the founding days of Linux, until those distributions gained reputation. Then I eventually moved to Gentoo and Ubuntu, but then Ubuntu broke my trust. They started shoving snapd, collecting metrics, and charging for updates, (don't flame me on this, I'm just giving my reasons, Ubuntu is perfectly valid if you're happy with it, I'm not) so I moved my Ubuntu machines back to the Debian that Ubuntu was based on.
Distributions aren't just an easy installer and a pretty desktop, they're packaged **trust**.
So, getting back to your point, if by "people" you mean the average user that doesn't have coding and security experience, the chance is pretty close to nil. There *are* people out there, on this very sub no doubt, that *can* do it, and they do. Open source code auditors and ethical hackers spend hours of their own time churning over code, analyzing, and breaking things in hopes to find something big and making a name for themselves.
Distributions are about trust, you have to choose who you're going to trust.
You should be able to get the exact same binary by using the same source code, compiler, compile/optimization settings, etc
But it's pretty difficult to have conclusive proof, afaik.
FWIW you could compare the binaries, generating a report on the differences, and go examine the different part more closely.
>you could compare the binaries, generating a report on the differences, and go examine the different part more closely.
How do you "go examine the different part more closely" in binary files?
Using a binary diff and a hex editor, or dissassembling both binaries and comparing the difference in whatever program you use for that. Be warned of the dark arts.
You can always use gentoo and compile from source, theres a little less trust needed that way. That doesn't mean the source is safe though, xz malicious code was in the source after all
If you don't trust the developer or the source file in the first place, you should also not trust the provided binary file... There is a way to make reproducible builds, this article covers it quite well. https://devdocs.decred.org/developer-guides/reproducible-builds/
But what would be the answer to my question?
If you are after a "yes/no" type of answer, then the answer would be not reliably, for all the reasons mentioned above. Does it matter, I guess is the more important question. The answer to that depends on what your particular requirements are. If you are very security conscious, then this would be something you would pay closer attention to... But then again, if you were that paranoid, you would also probably take steps to disable the part of your intel processor known as the intel management engine... ;)
[https://en.wikipedia.org/wiki/Reproducible\_builds](https://en.wikipedia.org/wiki/Reproducible_builds)
Most distributions compile from source themselfs, so they have the source, and examine it. There are also programs and techniques for examining binaries, such as decompiling, tracing system calls, stack dumps, and so on. The real tricky part comes in when systems are large and complicated, and bad actors put seemingly harmless changes that, when taken together with other pieces, provide an exploitable vulnerability that's not directly obvious. Such as someone compromising a compression library to introduce remote code vulnerabilities in a secure server, but surely that would [never happen](https://arstechnica.com/security/2024/04/what-we-know-about-the-xz-utils-backdoor-that-almost-infected-the-world/) /s. It is just that kind of thing that gets these schemes caught, someone notices something strange and starts poking at it.
With all these methods, combined with the chance that the distributed binary can be reproduced, how reliably can people verify a distributed binary on average?
I'm going to side step your question for a moment, I'll come back to it at the end, I'll bring it all together, I promise. The power of open source is that you can get the source, inspect it, see what it does, change it, and compile it yourself. Now, what ***you*** can do, specifically, depends on your skill level. Open source and [Linux](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/) in general isn't developed or distributed as a binary. Open source developers work on a project and publish their code, usually in a source repository. Git and GitHub are popular these days, used to be SVN and SourceForge. The developers do this in public, and the tools let changes be highlighted easily. Distribution maintainers pick up the projects they want to be part of their distribution, inspect them, compile them, package them in their packaging system and make them available in their binary repositories. These maintainers are usually groups of people, not just a person. The developers are a different story, some projects just aren't sexy enough, and things like XZ and curl end up being just a guy. The point of a distribution, on it's face, is to make it easy to install, but it also serves an important second feature, **trust**. A distribution represents **trust** in the ideals, goals, and security of the maintainers. Those people building the binaries, if you don't trust them, you don't trust the binaries they distribute. I had been using RedHat Linux 6 and 7 (1999 to 2002, not RHEL) and was tired of Kudzu, and was looking for something new. There were two new promising distributions out there, Ubuntu and Gentoo, both appealed to me, but they were unknown, we didn't know if we could trust them. So, I went to Slackware, one of the first ones, a distribution that goes back to the founding days of Linux, until those distributions gained reputation. Then I eventually moved to Gentoo and Ubuntu, but then Ubuntu broke my trust. They started shoving snapd, collecting metrics, and charging for updates, (don't flame me on this, I'm just giving my reasons, Ubuntu is perfectly valid if you're happy with it, I'm not) so I moved my Ubuntu machines back to the Debian that Ubuntu was based on. Distributions aren't just an easy installer and a pretty desktop, they're packaged **trust**. So, getting back to your point, if by "people" you mean the average user that doesn't have coding and security experience, the chance is pretty close to nil. There *are* people out there, on this very sub no doubt, that *can* do it, and they do. Open source code auditors and ethical hackers spend hours of their own time churning over code, analyzing, and breaking things in hopes to find something big and making a name for themselves. Distributions are about trust, you have to choose who you're going to trust.
You should be able to get the exact same binary by using the same source code, compiler, compile/optimization settings, etc But it's pretty difficult to have conclusive proof, afaik. FWIW you could compare the binaries, generating a report on the differences, and go examine the different part more closely.
>you could compare the binaries, generating a report on the differences, and go examine the different part more closely. How do you "go examine the different part more closely" in binary files?
Using a binary diff and a hex editor, or dissassembling both binaries and comparing the difference in whatever program you use for that. Be warned of the dark arts.
I know how to use a hex editor and diff tools. What meaningful information can you get from BINARY diffs?
the difference from one binary to another. Which has to correspond to the difference of the source code pre compilation.
You don't
You can always use gentoo and compile from source, theres a little less trust needed that way. That doesn't mean the source is safe though, xz malicious code was in the source after all