| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch, the key-migration.sh script only migrated the keys the
first time it ran. To do that, in that first run, it also creates the
/data/system/.key-migration-done file, and in subsequent runs it skips
the key migration if that file was present.
It probably did that to not redo the same operations again and again
either to limit the data loss risk by not doing any filesystem writes
and/or to speedup the boot process.
However if we have more than one maintainer or keyset changes over time,
users will need to run this script the first time, and at the second
change later on, the new script will not run. In addition users also need
to be able to create such script themselves and run them whenever they
need to in order to migrate to self builds, or downgrade.
Using a revision system to do that would be error prone as users and
developers would need to not forget to bump the revision to make the
script run. Using an automatic revision with the hash of the script
content also has issues as running the same script twice (for instance
by doing an upgrade, then a downgrade and then an upgrade) wouldn't
work.
Running the script each time ensure that all uses cases work, at the
cost of speed: in the recovery, with all Replicant 4.2 and 6.0 keys
up to Replicant 6.0 0004 RC2, running the script takes about 5s on
a Galaxy SIII (GT-I9300):
# time sh ./key-migration.sh
Key migration done
0m4.55s real 0m1.07s user 0m3.18s system
We also ensured that no writes were made to the packages.xml file
if nothing had to be changed. This increases the risk during the
key update as no backup of the packages.xml is done, however this
decreases the risk subsequently as no writes are made anymore.
Prints were also added to inform the user of if the script ran fine,
and if not why it didn't.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
|
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 adds a new python script for generating the key-migration.sh
script that will be added to the vendor_replicant repository.
Generating the key-migration.sh script with a python script enables 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 script
could also be run manually in the recovery and also make the migration to
self-built images much easier.
- The generated 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).
- The call to otasigcheck.sh during the installation of new Replicant
versions will be removed in the build repository.
- otasigcheck.sh will be removed in the vendor_replicant repository.
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
This key-migration.sh script has been generated by the following command in
the Replicant source code directory:
$ ./vendor/replicant-scripts/images/gen_key_migration_script/gen_key_migration_script.py \
gen-script \
vendor/replicant/prebuilt/common/bin/key-migration.sh \
vendor/replicant-data/distros/releases/certificates/ \
vendor/replicant-security/
This work is based on the following commit from the android_vendor_cm
repository[1]:
2f7c7decc Add startup script to update the package signatures
commit 2f7c7decc4cd5b42f044a7841a74468e4cacd694 (refs/changes/27/156327/3)
Author: Gabriele M <moto.falcon.git@gmail.com>
Date: Fri Jan 13 17:03:45 2017 +0100
Add startup script to update the package signatures
This allows to jump straight to LineageOS without wiping
userdata first.
Change-Id: I208bcada9380cbd69f3bec6c64e3c9e0eb1104c8
[1] https://github.com/LineageOS/android_vendor_cm.git
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
