6 ms·

The developer would still be able to post the shasum though, right? If so this would still be detectable.

izacus 5y ago
Thing is, Google wants to repackage the apps to lower and optimize download sizes. The developer can't know what SHA hash of an optimized partial bundle is.
- dbrgn 5y ago
  Yup, I'm pretty sure this makes reproducible builds totally impractical for any apps installed through the Play Store. Apps that currently provide reproducible builds: Signal, Threema, Telegram. (Probably others as well.)
- pdkl95 5y ago
  If "optimize[d] download sizes" is the goal, Google could simply release a tool that performed the compression/etc on a bundle (pre-signing) and require[1] that apps must be processed by the tool before submission. [1] Google could easily verify this by making the tool output a fixed point; running the tool on an already processed bundle shouldn't change anything.
  - Gaelan 5y ago
    That doesn't work if there's a large and possibly growing matrix of hardware/OS/whatever combinations they're trying to optimize for.
    - pdkl95 5y ago
      I've only mentioned one example of how such a tool could work. There are many ways this typ0e of system could be designed. For an alternative that doesn't depend on the number of output combinations, see GauntletWizard's example[1] that uses a signed manifest of files. [1] https://news.ycombinator.com/item?id=27177425 https://news.ycombinator.com/item?id=27177425
    - Avamander 5y ago
      If they have the tool, they could give the tool. It's not like it's very often that a totally new arch + DPI + Android version combination appears.
      - cwyers 5y ago
        The point is, if you build a signed app meant to run on any device, you are going to include code/assets for all of them. What Google wants to do is basically "tree-shake" the APK so that when you download it, it only contains what you need for your device.
        Avamander 5y ago
        Still, if they can generate the "shaken-down" version the dev could as well.
  - izacus 5y ago
    That tooling exists for a few years now - I don't think a lot developers opted to use it though.
- derefr 5y ago
  Google could publish the code they're going to use to do the transformation step (as e.g. a Docker image), and the developer could audit the result by optionally independently running the same code themselves, at any time after publication. As long as the code Google published was deterministic, the developer should be able to use it to reproduce a binary with the same the SHA as the one offered centrally. This is the same process that package maintainers (e.g. Debian, Mozilla, Tor) go through to produce reproducible (i.e. verifiable, deterministic) binary packages: they enable arbitrary users to run a copy of the packaging + distribution infrastructure on their own machine, such that they can watch it all go and see that it spits out the same thing the remote server does.
- akomtu 5y ago
  "optimizing download size" is a lazy distraction when an OS update can be 1 GB. Goggle really wants to modify the apps for selected individuals. To sugar coat the pill, they came up with the size optimizing story (and reducing carbon footprint, probably).
rocqua 5y ago
Nope, because the delivered bundle is going to be different from the APK the developer uploaded. This is the actual goal of this system. And when used for good, it allows much smaller app downloads. However, it also makes developer signing harder (so google decided to eliminate it) because every app bundle is going to be a different file. As a side effect, this also kills 'reproducible builds', unless the bundling process by google is itself reproducible.

Thing is, Google wants to repackage the apps to lower and optimize download sizes. The developer can't know what SHA hash of an optimized partial bundle is.

dbrgn 5y ago
Yup, I'm pretty sure this makes reproducible builds totally impractical for any apps installed through the Play Store. Apps that currently provide reproducible builds: Signal, Threema, Telegram. (Probably others as well.)
pdkl95 5y ago
If "optimize[d] download sizes" is the goal, Google could simply release a tool that performed the compression/etc on a bundle (pre-signing) and require[1] that apps must be processed by the tool before submission. [1] Google could easily verify this by making the tool output a fixed point; running the tool on an already processed bundle shouldn't change anything.
- Gaelan 5y ago
  That doesn't work if there's a large and possibly growing matrix of hardware/OS/whatever combinations they're trying to optimize for.
  - pdkl95 5y ago
    I've only mentioned one example of how such a tool could work. There are many ways this typ0e of system could be designed. For an alternative that doesn't depend on the number of output combinations, see GauntletWizard's example[1] that uses a signed manifest of files. [1] https://news.ycombinator.com/item?id=27177425 https://news.ycombinator.com/item?id=27177425
  - Avamander 5y ago
    If they have the tool, they could give the tool. It's not like it's very often that a totally new arch + DPI + Android version combination appears.
    - cwyers 5y ago
      The point is, if you build a signed app meant to run on any device, you are going to include code/assets for all of them. What Google wants to do is basically "tree-shake" the APK so that when you download it, it only contains what you need for your device.
      - Avamander 5y ago
        Still, if they can generate the "shaken-down" version the dev could as well.
- izacus 5y ago
  That tooling exists for a few years now - I don't think a lot developers opted to use it though.
derefr 5y ago
Google could publish the code they're going to use to do the transformation step (as e.g. a Docker image), and the developer could audit the result by optionally independently running the same code themselves, at any time after publication. As long as the code Google published was deterministic, the developer should be able to use it to reproduce a binary with the same the SHA as the one offered centrally. This is the same process that package maintainers (e.g. Debian, Mozilla, Tor) go through to produce reproducible (i.e. verifiable, deterministic) binary packages: they enable arbitrary users to run a copy of the packaging + distribution infrastructure on their own machine, such that they can watch it all go and see that it spits out the same thing the remote server does.
akomtu 5y ago
"optimizing download size" is a lazy distraction when an OS update can be 1 GB. Goggle really wants to modify the apps for selected individuals. To sugar coat the pill, they came up with the size optimizing story (and reducing carbon footprint, probably).

rocqua 5y ago

Nope, because the delivered bundle is going to be different from the APK the developer uploaded. This is the actual goal of this system. And when used for good, it allows much smaller app downloads. However, it also makes developer signing harder (so google decided to eliminate it) because every app bundle is going to be a different file. As a side effect, this also kills 'reproducible builds', unless the bundling process by google is itself reproducible.