In device root directory, we have the following symlinks:
- /odm/app -> /vendor/odm/app
- /odm/bin -> /vendor/odm/bin
- /odm/etc -> /vendor/odm/etc
...
This allows the Generic System Image (GSI) to be used on both devices:
1) Has a physical odm partition, where those symlink will be hidden
when /odm is used as the mount point
2) Has no physical odm partition and fallback to /vendor/odm/.
We can't just have the symlink /odm -> /vendor/odm, because the former
devices won't have /vendor/odm directory, which leads to mount failure
when the mount point /odm is resolved to /vendor/odm.
The existing /vendor/odm/build.prop won't be loaded in the latter
devices, because there is no symlink:
- /odm/build.prop -> /vendor/odm/build.prop.
Note that init blocks reading through direct symlinks (O_NOFOLLOW) so
the above symlink won't work either. This CL moves the odm build.prop
to /odm/etc/build.prop for init to load it (symlinks in earlier
components of the path will still be followed by O_NOFOLLOW).
Bug: 132128501
Test: boot a device and checks /odm/etc/build.prop is loaded
Test: make dist with an odm.img, checks $OUT/odm/etc/build.prop is loaded
Change-Id: I6f88763db755c9ec6068bfdd9cee81c19d72e9d7
Merged-In: I6f88763db755c9ec6068bfdd9cee81c19d72e9d7
(cherry picked from commit 6c62884000)
This CL moves SignApex() from sign_target_files_apks into apex_utils,
and adds sign_apex that allows signing a standalone APEX file directly.
Test: Run the following command and check the output file.
$ build/make/tools/releasetools/sign_apex.py \
-v \
--container_key \
build/make/target/product/security/testkey.x509.pem \
--payload_key external/avb/test/data/testkey_rsa4096.pem \
--payload_extra_args \
"--signing_helper_with_files ./signing-helper.sh" \
foo.apex \
signed-foo.apex
Test: Run sign_target_files_apks.py on crosshatch target_files.zip.
Change-Id: I4b2422fd5cb1c60a3aa94511475e2a0e5b1666ca
Some properties had 'test-keys' still set
after signing the target files zip for release.
These properties are now added to the RewriteProps
method.
Bug: 131810966
Test: manual
Test: `atest releasetools_test`
Change-Id: Ifb352ed28f5100f1e9f686d77e935723f7f6d3ae
For an PRESIGNED APEX, it has the following format, which should be
considered as a valid input.
name="foo.apex" public_key="PRESIGNED" private_key="PRESIGNED" container_certificate="PRESIGNED" container_private_key="PRESIGNED"
Bug: 131153746
Test: Run sign_target_files_apks.py on a target_files.zip with PRESIGNED
APEXes.
Test: python -m unittest sign_target_files_apks
Change-Id: I51076b0c6eddfb75637d37659a08009f0a88e931
We used to require explicitly setting both (e.g. `-e foo.apex=` and
`--extra_apex_payload_key foo.apex=` to skip signing `foo.apex`).
This CL allows specifying `-e` alone to achieve the same result.
However, if a conflicting `--extra_apex_payload_key` is also specified,
that would be considered as a config error.
Bug: 131153746
Test: Run sign_target_files_apks.py with `-e foo.apex=` alone to skip
signing foo.apex.
Test: Run sign_target_files_apks.py with `-e foo.apex=` and
`--extra_apex_payload_key foo.apex=key` and expect assertion error.
Change-Id: Ia747f59ee726b60bdb1445024e749320171064c2
The boot-debug.img should NOT be release signed and can only be used
if the device is unlocked. Adding a check to prevent the tool from
signing this debuggable boot.img.
See the following for more details about boot-debug.img:
https://android-review.googlesource.com/c/platform/build/+/947857
Bug: 126493225
Test: put a file /force_debuggable into boot.img, checks the following
command fails:
./build/tools/releasetools/sign_target_files_apks \
out/dist/*-target_files-*.zip signed-target_files.zip
Change-Id: Ia5232949cb9582d2b4eaa171d9e9f3fe7317d418
Previously it was following a wrong order by doing `zipalign` after
calling SignApk, which effectively compromised the signature. This CL
corrects the logic, and follows the same flow as in build system:
- Pack APEX file;
- `zipalign -f 4096`;
- Call SignApk to sign the container with `-a 4096` flag.
Bug: 129148142
Test: Run sign_target_files_apks.py on taimen target_files.zip. Boot the
image after signing.
Change-Id: I91bd3dce4f45c1891c5e122212a699f4808618fa
(cherry picked from commit 0e06cb0a8b)
For PRESIGNED APEXes, we should keep carrying the matching public keys
at /system/etc/security/apex.
Bug: 129148142
Test: Run sign_target_files_apks.py on a target_files.zip with presigned
APEXes. Check the output zip.
Change-Id: I2e941fd9b10e99d2db9df1e5308cbbe8c760177b
(cherry picked from commit bf3fb024cd)
Currently system_other AVB public key is placed in system.img.
However, this makes it's harder to have a *generic* system.img
across different product configs. Moving the key to /product
partition to allow more product-specific AVB keys.
Device board config can add /product/etc/fstab.postinstall,
to mount system_other with this key in /product. It can specify
different mount options, file systems, verity settings, etc., in
this product-specific fstab as well.
Bug: 123611926
Test: `make productimage` checks the following is generated.
$OUT/product/etc/security/avb/system_other.avbpubkey
Also checks it's included in $OUT/installed-files-product.{json, txt}
Test: run the following command and checks that
PRODUCT/etc/security/avb/system_other.avbpubkey is updated:
./build/tools/releasetools/sign_target_files_apks \
--avb_system_other_algorithm SHA256_RSA2048 \
--avb_system_other_key external/avb/test/data/testkey_rsa2048.pem \
out/dist/*-target_files-*.zip signed-target_files.zip
Change-Id: I6804f29941bec54375d80bd68a5aedb5c23b842e
This CL adds support that allows treating an APEX as pre-signed. We can
skip signing an APEX with `-e <apex-name>=` and
`--extra_apex_payload_key <apex-name>=`. Note that the payload_key and
container_key must be in consistent state - either they're both
PRESIGNED or none of them is. CheckApkAndApexKeysAvailable() has been
updated to perform the sanity check.
Bug: 123716522
Test: Run sign_target_files_apks.py with the above flags.
Test: python -m unittest test_sign_target_files_apks
Change-Id: Id1e2f3f2facd4a97a385983cc9b78c028f7e7e73
The keys_info in the touched code is a tuple, which is immutable.
Bug: 123716522
Test: Run sign_target_files_apks.py with '-e foo.apex=bar' that replaces
the APEX container key.
Change-Id: I4e57e46c93a56b7f6646764d021ebb42c19bf7f5
Bug: 123716522
Test: Run sign_target_files_apks.py to sign a target_files with APEXes.
Test: Run check_target_files_signatures.py on signed artifact.
Test: python -m unittest test_sign_target_files_apks
Change-Id: I3fa13e3d9461cf5e0838e0572d436e218164fe41
Other modules have switched to logging module. sign_target_files_apks.py
needs to init the logger to get the logs.
Test: Run `sign_target_files_apks.py -v`. Check outputs.
Test: Run `check_target_files_signatures.py -v`.
Change-Id: Ic68c019f6fb14840561885f1194ad6efdfdb7d82
Bug: 122608028
Test: Run sign_target_files_apks.py on a target-files zip that has split
super images (e.g. OTA/super_system.img).
Change-Id: Iaf7263790961a897ea3f339f5af6b18cf253b946
Recovery can now parse the pem encoded x509 keys from a zipfile. So
instead of dumping the keys into a text file with some intermediate format,
we can simply create a zipfile with the keys.
Bug: 116655889
Test: make bootimage and check the generated zipfile, run sign_target_files_apks
Change-Id: Ib76feecfb26d6be713a07644e80ec96133759004
The recovery image already contains a copy of first stage init, so we
can boot unconditionally to the recovery image and instruct first
stage init whether or not to boot to Android or to recovery. In this
case, we need neither the kernel to mount /system as / nor a separate
partition for recovery, so this change modifies the build scripts to
allow this combination.
Bug: 114062208
Test: Boot pixel from recovery to Android with BOARD_USES_RECOVERY_AS_BOOT
But without BOARD_BUILD_SYSTEM_ROOT_IMAGE
Change-Id: Icd047afb7f22d2724b3bcaca1aa0c837426dcce7
The new suffix distinguishes the new care_map from the ones in plain
text format; and thus the old update_verifier won't report an error
upon parsing failures.
Bug: 115740187
Test: Generate OTA files for Pixels
Change-Id: Ia782afd8cbb0f4bb8c363edaa00e92ab302d5d1b
The recovery image will be packed under BOOT/RAMDISK only if
system_root_image and recovery_as_boot both are true (e.g. non-A/B
devices launched since P).
Bug: 113191245
Test: Run sign_target_files_apks.py on a target_files file that uses
system-as-root but not recovery-as-boot.
Change-Id: I262a268055c6b5078d21694b5094a1c393d0d37c
They used to be installed under recovery/root/etc. This CL moves the
files to the new location and creates a symlink from /etc to /system/etc
(done by the rule in system/core/rootdir). This gives similar layout
between normal boot and recovery, and allows installing prebuilt_etc
files with Soong (`recovery_available: true`).
As part of the change, we no longer need the whitelisting rule for
mke2fs.conf.
Bug: 112780007
Test: Build with other changes in the topic (aosp_taimen-userdebug).
Check the generated files under recovery (/etc being a symlink to
/system/etc).
Test: Boot into recovery. Verify basic functionalities (`adb shell` and
`adb sideload`, factory reset).
Test: `build/soong/build_test.bash --dist`
Change-Id: Ibb6dea6f179a339f0c2d0fd8ba05ec0085b79a12
We may pack prebuilts that end with ".apk" into target_files zip, via
PRODUCT_COPY_FILES. META/apkcerts.txt won't contain the cert info for
such files, and we want to keep them as is while signing, despite of the
".apk" extension.
This CL adds "--skip_apks_with_path_prefix" option to
sign_target_files_apks.py. APKs with matching prefixes will be copied
verbatim into the signed images. The prefix should match the entry names
in the target_files (e.g. "SYSTEM_OTHER/preloads/"). The option may be
repeated to specify multiple prefixes.
Note that although we may skip signing an APK file with "-e ApkName=".
This would skip *all* the APK files with the matching basename.
"--skip_apks_with_path_prefix" allows matching the exact prefix.
For example:
$ ./build/make/tools/releasetools/sign_target_files_apks.py \
--skip_apks_with_path_prefix SYSTEM_OTHER/preloads/ \
--skip_apks_with_path_prefix PRODUCT/prebuilts/PrebuiltApp1 \
--skip_apks_with_path_prefix VENDOR/app/PrebuiltApp2.apk \
target_files.zip \
signed-target_files.zip
Bug: 110201128
Test: Run the command above and check the logs.
Test: `python -m unittest test_sign_target_files_apks`
Change-Id: I7bd80b360917cef137cf1e7e8cfa796968831f47
Test: Run sign_target_files.py to sign a target_files.zip.
Test: `python -m unittest test_sign_target_files_apks`
Change-Id: Ie795d1bce7bae6af427832283e3d10bfecad80c5
Since we have been carrying test certificates in testdata/ for other
tests, do the same for test_sign_target_files_apks.py. Copy
verity.x509.pem from build/target/product/security/ to testdata/ for
that purpose.
Also capture the stderr output in ReplaceVerityKeyId().
Test: python -m unittest test_sign_target_files_apks
Change-Id: Ie11e042086952e8a4a5a63950cb0b16cc436b7e6
When calling 'openssl x509 -pubkey' to extract the public key from a
certificate, openssl 1.0 and 1.1 handle the '-out' parameter
differently. openssl 1.0 doesn't write the output into the specified
filename, which leads to the payload verification failure in
check_ota_package_signature.VerifyAbOtaPayload(). This CL addresses
the issue by always collecting the output from stdout instead.
It also refactors the two copies into common.ExtractPublicKey(), and
adds unittest. get_testdata_dir() is moved into test_utils.py that holds
common utils for running the unittests.
Bug: 72884343
Test: python -m unittest test_common
Test: python -m unittest test_ota_from_target_files
Test: Run sign_target_files_apks with '--replace_ota_keys' on marlin
target_files zip. Check the payload pubkey replacement.
Test: Trigger the tests with forrest, and tests no longer fail on
machines with openssl 1.0.1.
Change-Id: Ib0389b360f064053e9aa7cc0546d718e7b23003b
Mostly cosmetic changes, such as replacing print statement with print
function. Also change 'import cStringIO' to optionally look for the one
in io module, to allow Python 2/3 compatibility.
Test: pylint --rcfile=pylintrc sign_target_files_apks.py
Test: Run sign_target_files_apks.py on marlin target_files.zip.
Change-Id: I4dc98b01da6f89e624114bbca5522f659901c1f2
For devices using derived fingerprint (i.e. /system/build.prop doesn't
contain ro.build.fingerprint, but has ro.build.thumbprint instead), the
current code (in android.os.Build) doesn't have a matching logic to do
the same for ro.vendor.build.fingerprint. This means we will see
ro.build.thumbprint in /system/build.prop, while there's no matching
ro.vendor.build.thumbprint in /vendor/build.prop.
From signing script point of view, it should just apply the tag
replacement (e.g. test-keys -> release-keys) for whatever it sees when
signing a target_files.zip.
This CL also adds unit tests for EditTags() and RewriteProps().
Fixes: 27950003
Test: Use 'sign_target_files_apks.py' to sign a target that uses derived
fingerprint and vendor partition. Check VENDOR/build.prop.
Test: python -m unittest test_sign_target_files_apks
Change-Id: I09019da970840cd82f54b68a32b4e94984bc1d8d
In some non-A/B setups, recovery.img is still being used. If AVB is
enabled, we currently don't add a hash footer to recovery.img nor do
we include the hash digest in vbmeta.img. This CL fixes that.
This was tested on a build with the following settings
TARGET_NO_RECOVERY := false
BOARD_USES_RECOVERY_AS_BOOT := false
BOARD_BUILD_SYSTEM_ROOT_IMAGE := false
BOARD_RECOVERYIMAGE_PARTITION_SIZE := 33554432
BOARD_AVB_RECOVERY_ADD_HASH_FOOTER_ARGS := --prop foo:bar
and then it was verified using 'avbtool info_image' that recovery.img
has a hash footer and a 'foo' property with the value 'bar'. This was
also checked successfully for vbmeta.img.
Test: See above.
Bug: None
Change-Id: I98124d5661ea768411416fa8d2a2ae6cc664fdc8
When signing a target_files.zip, the OTA certificate specified by
default_system_dev_certificate could be replaced with a mapped key. When
that happens, we must explicitly specify --package_key when generating
OTA packages with ota_from_target_files.py. Otherwise the OTA package
will be signed with the wrong key, which leads to verification failures.
This CL updates the default_system_dev_certificate value in
misc_info.txt accordingly.
Test: Sign a target_files.zip and replace the OTA key. Check
META/misc_info.txt in the generated target_files.zip.
$ ./build/make/tools/releasetools/sign_target_files_apks.py -v \
--replace_ota_keys \
-k build/target/product/security/testkey=build/target/product/security/platform \
out/dist/aosp_marlin-target_files-eng.tbao.zip \
signed-marlin-target_files-test.zip
Change-Id: I093234b5add3e27c5b3887cefeffd74e6f0a3e98
Compressed APKs can be identified by a "compressed=<ext>" entry in
the apkcerts.txt file. When we encounter such an entry, we need to
decompress the file to a temporary location before we process its
certs. When we're signing, we should also recompress the package
after it's signed.
Bug: 64531948
Test: ./build/tools/releasetools/check_target_files_signatures.py
Test: ./build/tools/releasetools/sign_target_files_apks.py
Test: compared signed output before / after this change, verify that
it's bitwise identical when no compressed APKs are present.
Change-Id: Id32e52f9c11023955330c113117daaf6b73bd8c2
Accidentally broken by the cherry-pick in commit
f829b40c48 - the original CL in oc-dev
doesn't require the 'import stat' line.
Bug: 63629728
Test: `pylint --rcfile=pylintrc sign_target_files_apks.py`
Test: Successfully sign a build with sign_target_files_apks.py.
Change-Id: I94be613fb2219597148c4339ac33fc93d0cdae47
Currently we're writing META/misc_info.txt to the new TF.zip during
ReplaceVerityPrivateKey(). We should delay that until we have replaced
everything in need. Otherwise we won't be able to replace/overwrite
that zip entry (unless `zip -d` first).
This CL also cleans up the return value of ReplaceVerityPublicKey() and
ReplaceVerityKeyId(), since the caller no longer needs the values.
Test: sign_target_files_apks.py and check the generated signed TF.zip.
Change-Id: I9fbd7182247728281519e5e3971557f6b018ad65
(cherry picked from commit 46a5999a02)
This patch tries to fix the problem where the default properties need
to go with the system image especially on non-AB devices where
/default.prop is on the ramdisk image. A symlink is created at
/default.prop for backward compatibility.
Bug: 37815285
Test: Tested with ag/2416542. Booted pixel phones, checked the location
of prop.default, verified the symlink, checked a few properties
(via adb shell getprop) and manually tested a few apps (Camera,
Maps etc).
sign_target_files_apks.py was tested with:
sign_target_files_apks -o -e DynamiteLoader.apk= -e DynamiteModulesA.apk= \
-e DynamiteModulesB.apk= -e DynamiteModulesC.apk= -e DynamiteModulesD.apk= \
-e GoogleCertificates.apk= out/dist/*-target_files-*.zip signed-target_files.zip
Booted to recovery and ran 'adb sideload' successfully.
Change-Id: I1a9a2ba49c8252afc13ced3dea71253afbd3091e
Merged-In: I1a9a2ba49c8252afc13ced3dea71253afbd3091e
(cherry-picked from 4fbbe4578bb10d54292d9b243edf4999fddf1c93)
This patch tries to fix the problem where the default properties need
to go with the system image especially on non-AB devices where
/default.prop is on the ramdisk image. A symlink is created at
/default.prop for backward compatibility.
Bug: 37815285
Test: Tested with ag/2416542. Booted pixel phones, checked the location
of prop.default, verified the symlink, checked a few properties
(via adb shell getprop) and manually tested a few apps (Camera,
Maps etc).
sign_target_files_apks.py was tested with:
sign_target_files_apks -o -e DynamiteLoader.apk= -e DynamiteModulesA.apk= \
-e DynamiteModulesB.apk= -e DynamiteModulesC.apk= -e DynamiteModulesD.apk= \
-e GoogleCertificates.apk= out/dist/*-target_files-*.zip signed-target_files.zip
Booted to recovery and ran 'adb sideload' successfully.
Change-Id: I1a9a2ba49c8252afc13ced3dea71253afbd3091e
We should only disallow zip64 for the image and OTA zips (because we
don't have zip64 support in libziparchive yet). But target_files zips
are fine to use zip64 with host tools (and we already do that in
add_img_to_target_files.py).
This CL also sets the default compression method to DEFLATED when
creating the signed TF.zip.
Test: sign_target_files.apks.py signing a large TF.zip passes.
Change-Id: I8043739860604134fa1166e920c95c28797bbcc1
Currently we're writing META/misc_info.txt to the new TF.zip during
ReplaceVerityPrivateKey(). We should delay that until we have replaced
everything in need. Otherwise we won't be able to replace/overwrite
that zip entry (unless `zip -d` first).
This CL also cleans up the return value of ReplaceVerityPublicKey() and
ReplaceVerityKeyId(), since the caller no longer needs the values.
Test: sign_target_files_apks.py and check the generated signed TF.zip.
Change-Id: I9fbd7182247728281519e5e3971557f6b018ad65
Currently we're building the boot/recovery image twice, which is
redundant. And b/38455129 shows a problematic case when the image
from two builds doesn't match. We should only build the recovery
image once in the add_img_to_target_files.
Bug: 62021378
Test: call sign_target_files_apk on an angler target file,
recovery-from-boot.p generates successfully; and SHA of recovery.img
matches the one in install-recovery.sh.
Change-Id: I01e033501d80c18a87cbb870300eee5c19a04441
We used to check for 'attr >> 16 == 0xa1ff' (i.e. 0o120777) to detect
symlinks in the input target_files zip (TF.zip). This becomes broken
after we switch to soong_zip, which packs symlinks with 0o120700.
This CL fixes the issue by using stat.S_ISLNK() instead.
Note that we don't need to stage the files with the exact permission
bits as in the input TF.zip. Because this part is covered by mkbootfs
by using the canned or the compiled-in fs_config - as long as the
files/directories are accessible and the symlinks are created.
Bug: 38455129
Test: sign_target_files_apks.py on bullhead TF.zip. Check the
checksums in SYSTEM/bin/install-recovery.sh.
Change-Id: I51c1fc9a257fb3f18c16c2ed71528abaa6f7d9c9
