Oddbean

The code can be shared while the internal development is kept private. Testing, iterations etc are not needed to be shared. It is a scale, but always the open process is preferred. Until there are reproducible builds the apk-s cannot be checked anyway. The Google Play versions cannot ever be reproducible due to the signature being part of the apk (correct me if I am wrong). Reviewing the code and building for myself would be better, but until then I at least use Obtainium to grab the binaries from github.

I hear you. But It is one thing to trust the binaries (apk) represent the published code on GitHub; at least there are people like nostr:nprofile1qqsydl97xpj74udw0qg5vkfyujyjxd3l706jd0t0w0turp93d0vvungppemhxue69uhkummn9ekx7mp0qy08wumn8ghj7mn0wd68yttsw43zuam9d3kx7unyv4ezumn9wshsz8thwden5te0dehhxarj9ekh2arfdeuhwctvd3jhgtnrdakj70vc385 who check the builds for us. Yet not even having the v0.2.3 and v0.2.4 code on GitHub, while binaries of these versions are being distributed via app stores for quite some time.... is pretty meh. At the very least, unprofessional. And yes, everybody should install from GitHub/Obtainium 👍 PS: I wished more projects publish Dockerfiles for builds, so regular normies can build themselves. The Build process is oftentimes so poorly documented, and/or requires manual steps that it's just a pain in the ass to build apks yourself, so ppl just trust whatever is published.

To say, APKs can never be reproducible because of the signature is disingenuous. Reproducible builds are about binary transparency and while technically you could argue if an app is reproducible when the provider packed a signature into the file and you managed to reproduce all but these 64B, it's a moot point as the important part is the binary transparency of the executable code. Now you could say that the signature might contain evil code, right? Then the rest of the app would still need to invoke that code. So yes, maybe there is a backdoor in the signature but as long as the signature is exclusively uses as signature, it won't work as a backdoor. And if some part of the app uses its signature in some creative non-signature way, auditors should scream foul regardless of what the signature is. The other problem with relaxing the definition of reproducibility is the package format. In Android, APK files are basically zip files but not quite. APK uses zip compression but also has extra data like the signature itself. But absent a flaw in the operating system, that extra data is not available to the app during runtime, so binary transparency is possible under some assumptions.

Thanks clarifying, was not aware that the signature can be that easily separated. Does that mean that in case there is a reproducible build method available I can take an apk, unpack and try to reproduce just the binary?

In the case of Android the approach we use is to compile the apk ourselves and then compare the results. Comparing involves unzipping both apks and then comparing file by file. This is necessary as zip compression can result in different bits depending on the version of zip being used but the uncompressed data matches. We also use diffoscope that provides more insight into signing blocks that are in parts that normal zip tools might ignore. A different approach is to compile the app, extract the signature from the official app, add the signature to the compiled app and then verify the signature. If it's valid, the file is reproduced with only the signature coming from the official file. In the case of hardware wallets, the signature is typically a block of binary at the start or the end of the file, too. We shift the burden of verification if other stuff might reside there and do harm to those that do actual code audits, which we do not provide at this point.