path: root/core
diff options
authorDenis 'GNUtoo' Carikli <>2020-08-23 01:23:39 (GMT)
committerDenis 'GNUtoo' Carikli <>2020-09-23 23:04:20 (GMT)
commite7e97a20a48885323e4603e6b2260e0d561107cf (patch)
tree95a254cf578366e70e4109510da3a47f59814027 /core
parentc090ab9e2d03975559587a0878f5b4276b74d0fd (diff)
Recovery: Remove check for matching application signatures with their dataHEADreplicant-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 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/ 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, 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 during the installation of new Replicant versions. - will be removed in the vendor_replicant repository - A new script ( 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 script will be added to the vendor_replicant-scripts repository to enable users and developers to generate a script with the keys they want. This should make downgrade easier as the could also be run manually in the recovery and also make the migration to self-built images much easier. Also, the script has already been removed in LineageOS 17.1 by the following commit in vendor/lineage: commit 95621f3c73b94a87ca4528748535bb114ae1613f Author: Michael Bestas <> 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 <>
Diffstat (limited to 'core')
0 files changed, 0 insertions, 0 deletions