I know open source programs can be better in terms of privacy and security. At least potentially. For example if a messaging app is open source, everyone can see codes of this program on Github. If the program has backdoor, anyone can see it.
But how can we be sure, codes of app on Google Play Store is same as codes of Github? Could it be compiled in a different code has backdoor?
In: Technology
The APK on Play Store *could* have been built from a different source than you are seeing, yes. It’s possible. If you think that’s a concern, you can build the APK yourself using the source code you’ve vetted, and install that on any phones you need it on using [developer options](https://www.greenbot.com/article/2457986/how-to-enable-developer-options-on-your-android-phone-or-tablet.html).
Yes this is a real problem. There is something called reprducable builds, so you get the exact version of all tools your app was build with and publish the executable and the hash. So everyone can check if the has matches the apks on google play.
You can’t really, which is among the reason why you should always be a tiny bit skeptical of all software you didn’t compile yourself if you have important concerns. However depending on the software in question you could always try building the software yourself and see if the binary matches up, or if there are some security aspects of the software that can be publicly tested or analyzed.
Open Source Software is something that you can modify as per your needs, share with others without any licensing violation burden.
When we say Open Source, the source code of the software is available publicly with Open Source licenses like GNU (GPL) which allows you to edit source code and distribute it. Read these licenses and you will realize that these licenses are created to help us.
The motive behind making this software is to create something which will be useful to users. When we say Open Source is free, the word free is not attached to the cost factor. Open-source software can be paid but source code must be attached to it. Also one of the main income sources for this software is service. By creating such software, you can always charge for services.
The simple philosophy of OSS is when we buy a vehicle then one can modify it, change its parts without the manufacturers’ consent (at cost of warranty of product though)but in the software world, this was not possible due to strict guidelines of EULAs we generally don’t read. OSS brings a concept that helps us to use software the same as we buy other things.
Yes, this is a potential issue. This is why the concept of a reproducible build exists.
The idea is that you specify exactly how a program needs to be built, provide a specific environment, and structure the process in such a way that every time you build, the result is the same. This for instance means the program can’t contain anything like timestamp saying when it was built, or a build number embedded into it.
This way anybody could rebuild the app and verify it matches what’s on the Play Store. Of course not everyone is going to do this, so there is some trust involved. But in these cases things can be verified by random volunteers that aren’t all part of the same group/company, which makes anything fishy noticeably harder.
You as an end user probably *can’t* verify it’s the same. However, contrarily to what everyone is saying thus far, you actually *can* verify the source code seen is what was used to build an application.
In the world of automated development pipelines (you push new code and it flows through unit testing, security scanning, and whatever other processes your workflow requires), the pipeline will build the artifact from a specific code commit. All testing/scanning/processing is then done with that artifact/code commit, then that artifact is published to the public *with a hash calculated that’s specific to that artifact*.
So assuming the hash of the built artifact matches the hash of the artifact that went through your pipeline, they are the exact same and haven’t been modified in any way (otherwise the hash would be different). Even re-building the artifact from the same commit but at a different time will change the hash.
Now, this is only useful information to an end-user if the developer publishes the above information publicly, which doesn’t usually happen, but even if they did you have to trust that the developer didn’t fake that information. From a corporate standpoint though, anyone with access to the pipeline can validate that the artifact they received is the artifact that went through testing (which means the exact code commit is the same and the artifact *cannot* have gone through any changes since it was built/tested).
This is indeed a problem. Mostly it’s handled via signing mechanisms, packages are cryptographically signed.
Sometimes problems do happen, especially in package ecosystems like NPM or PyPI that allow developers to pull in loads of code for others to use.
For over 5 years, Debian [1] has been working on an important part of this problem, [reproducible builds](https://reproducible-builds.org/). That is, making sure that this kind of checking is possible, by making sure that building a project doesn’t end up including extra information like the build timestamp or specific details of the system used to build the code.
[1] Debian is one of the most popular open-source Linux distributions, and one of the biggest packagers of open-source software.
Latest Answers