[guardian-dev] Manipulating App Bundles

[Hans-Christoph Steiner]

I think Google is being quite cunning in how they are rolling this out.
 They are making it mandatory for all "new" apps.  I assume that means
we get to keep on uploading APKs.  But then, once that takes effect,
then I imagine it'll be quite easy for them to fully flip the switch to
App Bundles.

While it is true that F-Droid manages the signing keys of most of the
apps we distribute, I think it is also important to note, in addition to
all that Marcus said, that we make extra efforts to publish as much of
the whole process as possible.  Of course, its the whole tool chain.
But then also the binary transparency log of the index, and the build logs.

We also have recipes for setting up your own verification rebuilder, a
lot of APKs are reproducible without trying:
https://verification.f-droid.org/verified.html

.hc


Michael Rogers:
> On 22/06/2020 15:53, Marcus Hoffmann wrote:
>> Hi,
>>
>> (I work on F-Droid)
>>
>> On 22.06.20 13:20, Mark Murphy wrote:
>>> On Sun, Jun 21, 2020, at 22:20, John Sullivan wrote:
>>>> Just a quick comment on that last part. It may be worth mentioning for 
>>>> a fuller picture that F-Droid signs the builds themselves because they 
>>>> build them themselves. They publish all of the source that they are 
>>>> building as well as the server software that does the build. Doesn't 
>>>> mean things are 100% reproducible, but it might be relevant to mention.
>>>
>>> The *intent* is for F-Droid to build the apps themselves solely from the original sources. With sufficient motivation ("those are lovely kneecaps you got there -- it would be a pity if we had to break them"), F-Droid could be convinced to deliver altered apps. And, as with the Google App Bundle scenario, there is nothing to stop them. That then puts the onus on app developers or the broader ecosystem to detect this, and I don't know if anyone is looking. Perhaps people are looking and I just don't know about it -- if you know of people who are, I'd love to hear about them!
>>
>> A targeted attack would be harder for F-Droid as you have no control
>> from which mirror a client will pull an updated index and no accounts or
>> other information beside the IP to identify a target. Untargeted attacks
>> should be relatively easy to detect as it's only the package index file
>> that needs to be monitored (and it is by various bots, etc.)
>>
>> But yes, we are working on a real solution to this, where different
>> entities build the same packages indenpendent from each other and the
>> client only installing an update once he got enough rebuilder
>> attestations from trusted parties.
> 
> It's worth mentioning that F-Droid also has a fantastic but not much
> used feature that allows an app to be signed with the developer's own
> key, as long as F-Droid can reproduce the supplied binary exactly from
> the published source. We use this for publishing the same Briar binaries
> through F-Droid and Google Play.
> 
> In theory Google could do something similar (without requiring the
> original APK to be built reproducibly): the developer would build the
> universal APK as usual, use bundletool to generate all the variant APKs,
> sign them, and upload the signatures along with the universal APK (and
> presumably some metadata, like the bundletool version) to Google Play.
> Google would then generate the same variant APKs and apply the
> developer's signatures.
> 
> Or, even simpler, the developer could just upload the variant APKs. A
> few hundred MB of bandwidth isn't a big cost to exclude the possibility
> of targeted backdoors...



-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556