[rb-general] Reproducible Android apps: resources.arsc

[Hans-Christoph Steiner]

Marcus Hoffmann:
> I'd like to provide a counterpoint to this:
> 
> On June 19, 2018 1:33:16 PM GMT+02:00, Hans-Christoph Steiner <hans at at.or.at> wrote:
>>
>>
>> Chris Lamb:
>>> Hi _hc,
>>>
>>>> I think the F-Droid buildserver should include disorderfs
>>>
>>> I'm afraid I can't put into words how much I dislike this. :(
>>>
>>> The ideal, "permanent" solution is not to locate options to regular
>>> filesystems to force them to sort entries (which don't exist alas…),
>>> but to fix the build tool and begin the admittedly arduous and
>> tortuous
>>> (!) journey of getting that upstream.
>>>
>>> (Or at least to attempt to fix the build tool; to jump straight into
>>> "applying" disorderfs to the solution seems highly premature.)
>>
>> Best case scenario, Google fixes this bug today, and releases it ASAP.
>> It will literally be a couple of years before the majority of app
>> builds
>> use that version of the build tools.  Most app devs do not often update
>> the versions of the build tools they are using.
> 
> This might have been the case in the past but currently android studio very aggressively suggests upgrading the build tools with a single click. Even to alpha or rc versions. The result is often that app authors use versions of the build tools that we barely can add to the build server in time.
> 
> Even more so when working with an author on enabling reproducible builds suggesting they upgrade their build tools is probably a very minor thing in this whole process.

_Some_ developers do always and rapidly upgrade.  To get past the 50%
mark of builds would take a lot longer.  Then that still leaves half
using old versions.


>> The F-Droid scenario is very different than the distro scenario because
>> F-Droid cannot enforce which versions of tools are used in build
>> process.  In Android, the model is that the developer is responsible
>> for
>> the whole build/release cycle, and the "distro" just moves binaries
>> around.
>>
>> We'd like to be shipping reproducible builds now, rather than waiting a
>> couple more years to see this take effect.
> 
> But adding disorderfs to the build process doesn't magically solve anything. This requires that upstream explicitly also uses that to build their apps which probably only very few are willing to go through. As manual workaround for those apps it be a hacky solution we can use right now. To get a more widespread adoption of reproducible android builds this doesn't seem to be too useful.

That is true.  If adding disorderfs to the F-Droid buildserver VM is a
lot of work, then it would not be worth it.  If it is not more than a
day, then I think it is definitely worth it because it will provide the
first guaranteed path to reproducible builds on Android.  People who
want to do that can set up local F-Droid buildserver to run their
release builds, and they'll get reproducible builds.

CiaranG, uniqx, and others are working on automating the deployment of
the F-Droid buildserver host.  CiaranG plans to use it to deploy the new
f-droid.org infrastructure as part of the stretch upgrade.  Then having
people run their own F-Droid buildserver instance will become a lot more
feasible.

.hc