search

RadarCOVID / radar-covid-android

Native Android app using DP^3T Android sdk to handle Exposure Notifications API from Google
Mozilla Public License 2.0
382 stars 84 forks source link

Request: open the automated build environment to the public #22

Closed cmoro-deusto closed 3 years ago

cmoro-deusto commented 4 years ago

In order to be fully open, build and release system should also be accessible. Together with Issue #21 would allow source-binary verification.

spanishkangaroo commented 4 years ago

@cmoro-deusto even when I see and share your point, this or reproducible builds won't allow to fully check 100% that the code published in Google Play is the same as the code and so on published on these repositories. When apps are published, code is minified, obfuscated, signed, etc. so the final apk from your "reproducible build" will never be exactly the same as the one published. In fact, they did not publish the actual source code for CheckSumUtil and JwtAuthorizationFilter (see README) and it definitely makes sense, as some people were trying to guess and hack the positive report system, that could lead into chaos.

cmoro-deusto commented 4 years ago

@spanishkangaroo a process similar to the one used by Signal could be implemented. Please see: https://github.com/signalapp/Signal-Android/blob/master/ReproducibleBuilds.md

cgimeno commented 4 years ago

Security by obscurity is not security at all. I support @cmoro-deusto on that

spanishkangaroo commented 4 years ago

@cgimeno I cannot agree more with you. I'm just saying that of course it will be better, but it will not fully solve every concern. Just check the apkdiff.py used for apk comparison, you're fully relying on it and it does not, for example, compare resources that could have hidden stuff.

cmoro-deusto commented 4 years ago

@cgimeno Indeed. @spanishkangaroo Of course you cannot compare "secrets", but you can compare the binaries. That's Signal's approach. The secrets should also live in the appropriate environment, not in the source code.

I have been unable to review the source completely, but apparently (I might be wrong) some of those secrets exist in source as properties and that's why they have been forced to strip them from the code.

I'm also not fully convinced that CheckSumUtil and JwtAuthorizationFilter apply to the mobile app (certainly the auth filter should only apply to the backend).

Nevertheless and to be clear I'm not trying to nickpick: I reckon more exposure of the build and release system would allow for more independent reviews. That should allow more confidence in the whole solution, leading to a bigger installation base, which is what we all should aim for.

spanishkangaroo commented 4 years ago

People that actually care about others, the current situation and themselves will download the app anyway. Even if the app leaks data to the government, that already know about all your illnesses and earnings; or to Google or Apple, whose source-closed operating systems you've been running for years. There is no point in caring that much about this app. Just common sense.

cmoro-deusto commented 4 years ago

@spanishkangaroo I respectfully disagree. The fact of opening the code is to show transparency and to allow independent reviews in order to increase confidence.

avecina commented 3 years ago

Thanks. We will take into account this suggestion for future improvements.