signapk currently accepts a Provider class that can be instantiated
and inserted before the signing. This commit adds support to specify
a -providerArg parameter that can be used to configure the Provider.
Prior to JDK 9 a Provider would accept a providerArg in a constructor
accepting a String; in JDK 9+ a Provider should first be instantiated
with the zero-arg constructor, then the configure method should be
called with the providerArg.
Bug: 142334653
Bug: 190974913
Fixes: 232134730
Test: Manually verified new Provider can be inserted with pre- and
post-JDK 9 behavior.
Change-Id: I96f027640c59d3357e8dcf656626d1601bfef861
Summary:
In my last diff, I've added mechanism to load private key from keystore.
However, that mechanism will reveal password as part of the java param.
This diff tries to use existing ANDROID_PW_FILE mechanism to support
password for keystore private keys (through stdin)
This diff also fix a null pointer bug in the existing password handling
Test: This diff has been tested locally, and could sign correctly with our
keystore with or without password
Tags:
Change-Id: Ie291ea8702a3b4d270b0f8689b023c3f290980a7
Summary:
Add two flags to load the keys from pkcs#11 keystore. When the option
-loadPrivateKeysFromKeyStore is specified, will load private keys from
the keystore with specified keyStoreName instead of load from file.
Test: make dist for arm_sunfish-user, which includes apk
and ota (wholefile) signing
Test:
- manually call signapk in Java11 (java9 may need additional
change to support), with statically registered pkcs#11 keystore, signed
both apk and ota-package.
- verified using apksigner and extracting otacert from ota-package, both
correct
Change-Id: I3efb8017f73d3d992c07ed4562acfef016a109fe
A new flag tells that the resulting file size should be aligned as well.
For example, signapk -a 4096 --align-file-size ... generates the output
file of 4K-aligned sized.
Bug: 192991318
Test: check built APEX file size.
APEX files should be sized as 4K-aligned.
Change-Id: I1c287e7219b4551bbb3e5957bdb64d80adfd3c39
Using jni_libs tells Soong to install the JNI library into
a genrule sandbox alongside the java binary.
Bug: 124313442
Test: m checkbuild
Change-Id: Ia550102c7aa483497f95ac2ea8bb01bce89ae9c1
Currently, it may be a good idea to let genrule module depend on
java_library_host by changing soong. To change signapk module type from
java_library_host to java_binary_host makes the genrule can depend on the
signapk module directly and generate the signapk.jar at the same time.
Test: for i in `seq 1 10` ; \
do\
make clean; \
make -j64 apexer_test_host_tools; \
done
Bug: 160632228
Bug: 157878202
Change-Id: I63ae661b9b419ddc6e69ccfc9a29fd28b116c0b5
Merged-In: I63ae661b9b419ddc6e69ccfc9a29fd28b116c0b5
(cherry picked from commit d8442b4c88)
Also add multi-cert support to prebuilt apps so that they can benefit
from the new lineage feature.
Test: m GoogleServicesFramework w/ modified build rules
Test: m PrebuiltGmsCore w/ modified build rules
Test: apksigner lineage -v --print-certs -in <built_module_path>
Fixes: 152897457
Change-Id: If7d5d4bd308629c8340231520214c76c8a568a65
If this flag is enabled, the v4 signature file, named [outputApkFile].idsig
will be generated along side the outputApkFile.
Test: atest PackageManagerShellCommandIncrementalTest
BUG: 149354175
Change-Id: I5bc78bbc8b666a490f3ab05e781bfd859575af58
This extends the original pin list generation to support specifying a
range within a file. If any part of a file is pinned, its local file
header in the APK file is pinned as well.
Test: Build cuttlefish.
Bug: 136040313
Bug: 135953430
Change-Id: I6de8c2b4c2f35c6bf257f61414c6bce761233e51
soong_ui is passing the Android.mk file list to Kati, and it ignores
Android.mk files found via symlinks, so we don't need the workarounds
for build/make/target/board/Android.mk and build/target/board/Android.mk
both existing.
We've got dist support in Soong now, so we can remove the signapk
Android.mk
Bug: 122332221
Test: m dist out/dist/signapk.jar out/dist/libconscrypt_openjdk_jni.so
Change-Id: I2ac9016b04146340c5ac80f7090d00e186023574
Migrate off of one target onto another that should be identical.
"conscrypt" is about to be refactored for on-device use and signapk
needs to be unaffected.
Bug: 113148576
Test: make checkbuild
Change-Id: I3cecb4cc8fb8349383a82c8e430c936651e0835a
A host build target was depending on a target that is intended for
on-device, repackaged (com.android.) use. This switches to using the
unbundled target instead.
Test: Build
Bug: 111055375
Bug: 111734251
Change-Id: Ie81dd7257a14756fc21fa6f956175e5bd2ff80c1
Following the new API contract, this effectively add extra padding
before central dir to make it 4KB aligned.
Test: build succeeded
Bug: 30972906
Change-Id: I7cac9d2c4371b473c88df867b3b2ae906443db10
This patch updates the logic to use the PRODUCT_IOT variable instead of
BRILLO.
Bug: 36702887
Test: `make`; Image doesn't have the dev key.
Change-Id: I1751e97d8cdfeba83c7e4720a017a5f4dcfd49da
Prior to this change, when signing APKs, the build system invoked
'aapt dump badging' on each APK, to detect the value to pass into
signapk as --min-sdk-version. Now that signapk uses the apksig
library, it can auto-detect that value on its own, thus avoiding the
need to invoke 'aapt dump badging' and thus speeding up the build
process.
The semantics of signapk's --min-sdk-version flag is changed by this
commit from having the default value of 0 to having the default value
of "auto-detect from APK".
P.S. The get-package-min-sdk-version-int is not removed from
core/definitions.mk in this commnit, because this function is used in
another project's .mk file and thus that .mk file needs to be modified
first.
Test: rm -Rf out/ && make
Change-Id: I0972fcf0abbde9cbf6794e6c05c743c77c8a78f9
The switch to apksig changed the Created-By header value in .SF file
from "1.0 (Android SignApk)" to "1.0 (Android apksigner)". This commit
reverts the value back to "1.0 (Android SignApk)".
Change-Id: I2fc462cade40a5b31bb6191996fd6f18fabbf08f
This moves build/tools/apksigner/core to its own project tools/apksig.
The move also renames the moved Java packages from
com.android.apksigner.core.* to com.android.apksig.* to reflect the
new name of the library.
Bug: 27461702
Change-Id: Iab812ae2b8f0a741014f842460c78e35bc249d43
Instead of specifying character encoding by name, the faster, cleaner,
and safer way is to use StandardCharsets.UTF_8.
Bug: 27461702
Change-Id: I897284d3ceeb44a21cc74de09a9b25f6aec8c205
26f00cda4b introduced a bug where an
APK entry's extra field is padded for alignment purposes when no
padding is necessary because the entry is aligned without any padding
bytes.
Bug: 27461702
Change-Id: Icb164dbaa26d9686412e2920318a9f40c5ce9751
This switches signapk's APK signing from its own signing logic to that
offered by apksigner-core library. OTA update package signing logic
remains inside signapk codebase.
Bug: 27461702
Change-Id: Ibf8435c555fe3f2b621d5189e7ae44f79082c810
Data of uncompressed APK entries is often aligned to a multiple of 4
or 4096 in the APK to make it easier to mmap the data. Unfortunately,
the current method for achieving alignment suffers from two issues:
(1) the way it uses the Local File Header extra field is not compliant
with ZIP format (for example, this prevents older versions of Python's
zipfile from reading APKs: https://bugs.python.org/issue14315), and
(2) it does not store information about the alignment multiple in the
APK, making it harder/impossible to preserve the intended alignment
when rearranging entries in the APK.
This change solves these issues by switching to a different method for
aligning data of uncompressed APK entries. Same as before, alignment
is achieved using Local File Header entry field. What's different is
that alignment is achieved by placing a well-formed extensible data
field/block into the extra field. The new field/block contains the
alignment multiple (e.g., 4 or 4096) as well as the necessary padding
(if any). Compared to the original alignment method, the new method
uses 6 more bytes for each uncompressed entry.
Bug: 27461702
Change-Id: I8cffbecc50bf634b28fca5bc39eb23f671961cf9
This removes the logic for JAR signing from -w (whole-file signing)
mode. This mode is designed specifically for OTA update packages. When
such packages are verified, their JAR signatures are ignored. Thus,
there is no need to JAR-sign in -w mode.
For context, OTA update packages are protected by a special signature
residing in the ZIP End of Central Directory record (at the very end
of the file). This is the signature verified when update packages are
being applied to Android.
Change-Id: Ia852a11ed6774ce746087cdd7f028b191ef6bc8b
Turns out APK signatures using SHA-256 with ECDSA are accepted only by
platforms with API Level 21 and higher, not 18 and higher.
Bug: 28296599
Change-Id: I3fab5be17bf3a9bdbf4d84d90d51448027c7e761
The rules for which digest algorithms are accepted by the Android
platform for APK signatures and OTA update package signatures are
different. For example, the set of digest algorithms accepted for APK
signatures depends on the signing key algorithm and the platform's
API Level. Whereas the set of digest algorithms accepted for OTA
update package signatures by Recovery depends on the list produced
by the build system, which in turn produces the list based on the
key algorithm and digest used in the signing certificate.
To reflect this reality, this refactoring CL explicitly separates
signapk's logic for choosing the digest algorithm to use for v1
signing from its logic for choosing the digest algorithm to use for
OTA update package signing.
Bug: 28296599
Change-Id: Ic7aa77e89622d727e985f8749071284746be7f45
Android platform does not support DSA with SHA-512. Thus, it does not
make sense to support this unsupported algorithm in APK Signature
Scheme v2.
Bug: 24331392
Change-Id: Ifba90ad5b11188bb968c28d9e0ed3f9cb13ce2e7
APK entry alignment logic assumes that input entries have zero-length
comment and extra fields. When the assumption is broken, the logic
silently breaks alignment of output entries. This happens, for
example, when the APK to be signed is already aligned and thus may
contain entries with non-empty extra fields.
Given that APKs are not supposed to use comment and extra fields for
anything useful and given that this signer already discards comment
and extra fields of compressed entries, this change makes the signer
discard comment and extra fields of STORED input entries as well.
This unbreaks the existing alignment logic.
Bug: 27814973
Change-Id: I8242b037e21ba7bcf45d0fe2afc8bfc47f1ec314
* Zip EoCD record comment length was referred to as 32-bit whereas it
is a 16-bit field. The implementation was fine, but the comment and
the naming of a constant were wrong.
* System.out.println was left over from early prototyping days.
Removed.
Bug: 25794543
Change-Id: I97199310d4b4451271a75bb6c6d0463e0b788be9
This is a follow-up to 6c41036bcf where
I forgot to update a section of OTA update ZIP code.
Bug: 26864066
Change-Id: Idbcde71d6377a16807e41c999120eeddd5b4d8a4
Brillo does not require Java. Add a JAVA_NOT_REQUIRED
flag to the build system to make the jdk requirment optional
Also don't build signapk for Brillo
BUG: 25281898
Change-Id: I31e68cc7d076bf6c234699c77c0ea1ea428be4f5
Previously, the timestamp was one hour ahead of NotBefore of the
signer's certificate, adjusted for the current timezone. With this
change the MS-DOS timestamp in output APK/ZIP files is
Jan 1 2009 00:00:00.
Bug: 26864066
Change-Id: Id6263c38ac7042489ab695454f8e0fb2d85a3958
APKs are now signed with the usual JAR signature scheme and then
with the APK Signature Scheme v2.
APK Signature Scheme v2 is a whole-file signature scheme which aims
to protect every single bit of the APK as opposed to the JAR signature
scheme which protects only the names and uncompressed contents of ZIP
entries.
The two main goals of APK Signature Scheme v2 are:
1. Detect any unauthorized modifications to the APK. This is achieved
by making the signature cover every byte of the APK being signed.
2. Enable much faster signature and integrity verification. This is
achieved by requiring only a minimal amount of APK parsing before
the signature is verified, thus completely bypassing ZIP entry
decompression and by making integrity verification parallelizable
by employing a hash tree.
Bug: 25794543
Change-Id: I275d2a6d0a98504891985309b9dfff2e0e44b878
This change makes signapk not reject the --disable-v2 command-line
flag which may be used by build scripts in some branches. The flag
is currently ignored.
This change is landed separately from the actual support for APK
Signature Scheme v2 because of unbundled branches which use prebuilt
versions of signapk.
Bug: 25794543
Change-Id: I900966244b8b6296b1f443bf98830cc7f7cc81a8
SHA-1 is deprecated, but the replacement SHA-256 is only supported
for JAR/APK and OTA update package signatures on API Level 18 and
newer. This change thus adds a --min-sdk-version command-line
parameter to signapk. When this parameter is set to 18 or higher,
SHA-256 is used instead of SHA-1. When the parameter is not provided,
SHA-1 is used same as before.
This change also removes any other digests from the MANIFEST.MF.
This is to ignore any MANIFEST.MF digests already there in the APK,
such as when re-signing an already signed APK.
Build scripts will be modified to provide the --min-sdk-version
parameter in a follow-up change. This is not done in this change
because of prebuilts which require a prebuilt version of signapk
to support this parameter before the build scripts can be modified.
Bug: 25643280
Change-Id: I6a2782e465600fe2a3ad0c10bd80db2b80a6fb76
Due to a bug introduced in 8562fd478d
SHA-1 digests of APK entries' contents were listed under wrong
attribute name. The effect is equivalent to not listing SHA-1
digests.
This change fix the issue by listing SHA-1 digests under the correct
attribute name. However, these digests are not that useful because:
(1) typically the digest of the MANIFEST.MF verifies and thus the
per-entry digests are ignored, and (2) per-entry digests of entries
with names longer than 64 characters are wrong in any case because the
digest generation code does not take into account that such names are
split over multiple lines.
An alternative to this change would be to completely omit outputting
per-entry sections of .SF files, thus saving space and speeding up APK
verification (.SF files would decompress faster).
Bug: 26513901
Change-Id: If95d58e9baa62b1113639fe70724e1e9c9f4e15c
