Recovery: Remove check for matching application signatures with their dataHEADreplicant-6.0-0004-transitionreplicant-6.0-0004-rc6replicant-6.0-0004-rc5-transitionreplicant-6.0-0004-rc5replicant-6.0-0004-rc4replicant-6.0-0004-rc3replicant-6.0-0004replicant-6.0

The applications built from Replicant are signed with a key that is
generated during the build procedure The issue is that the data of an
application becomes inaccessible to it if the application signature change.
This affects all the applications built during and signed during the build
of Replicant images, which includes all system applications.

This is why, during the installation of a new Replicant version, the
otasigcheck.sh is run: it verifies if the application signatures expected
by the applications data match the signatures of the new applications
that are part of the new Replicant image being installed.

Without this check, users installing a new Replicant minor version (like
Replicant 6.0 0004) and keeping the data from the previous minor version
(like Replicant 6.0 0003) with a key that change will make at least some
system applications like the launcher crash as they will not be able to
access their data.

If the check detects an incompatibility, on a Galaxy SIII (GT-I9300), we
end up the installation aborting and the following message being displayed
on the screen:
  detected filesystem ext4 for /dev/block/mmcblk0p12
  Can't install this package on top of incompatible data. Ples
  se try another package or run a factory test
  E:Failed to install /sideload/package.zip
  E:Please take note of all the above lines for reports.

This design has several issues:
- You cannot upgrade between Replicant minor versions if the keys signing
  applications shipped in the new version changed. This is really
  problematic as to upgrade, users need to delete all their application
  data and restart creating them from scratch which is very time consuming.
  With frequent updates that would becomes too much time consuming to do.
- It is also very fragile: if the data partition is encrypted,
  otasigcheck.sh cannot do the check, and the check is skipped completely,
  with the consequences explained before (the system applications end up
  not being able to access their data).

To fix that:
- This patch removes the call to otasigcheck.sh during the installation
  of new Replicant versions.
- otasigcheck.sh will be removed in the vendor_replicant repository
- A new script (key-migration.sh) will be added to the vendor_replicant
  repository. It will take care of migrating the applications data to
  the new keys during the first boot (so after the data partition will
  have been mounted).
- A python script generating this key-migration.sh script will be added
  to the vendor_replicant-scripts repository to enable users and developers
  to generate a key-migration.sh script with the keys they want. This
  should make downgrade easier as the key-migration.sh could also be run
  manually in the recovery and also make the migration to self-built images
  much easier.

Also, the otasigcheck.sh script has already been removed in LineageOS 17.1
by the following commit in vendor/lineage:
  commit 95621f3c73b94a87ca4528748535bb114ae1613f
  Author: Michael Bestas <mkbestas@lineageos.org>
  Date:   Sat Aug 4 17:46:35 2018 +0300

      Revert "ota: Validate any installed data's signature against our own"

      * otasigcheck doesn't work on encrypted devices and makes
        the zip installation fail since oreo.
      * The build part of this was never ported to oreo.

      This reverts commit aff5e54c4ef5fec7e67e830f83ee64424005d07c.

      Change-Id: I411f33c1db64844091c1692ef4706ae541925d4f

Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>

0 files changed, 0 insertions, 0 deletions