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
This also makes source files follow the standard directory structure
based on Java package names.
Bug: 25794543
Change-Id: Ie0b568057f836e56407f76d29eeacd28ab907ba8
This makes the signapk tool use Conscrypt (where possible) instead of
the platform-default JCA providers and the Bouncy Castle JCA provider.
This speeds up (by 10-30%) APK and OTA update signing because
Conscrypt's crypto primitives are backed by BoringSSL.
Previously, the signapk tool consisted only of the signapk.jar.
Because Conscrypt is backed by native code, signapk now consists of
signapk.jar and crypto_openjdk_jni shared library. This requires that
users of the tool be updated to provide a suitable -Djava.library.path
argument to the Java runtime. This change updates all known users of
the tool inside the Android source tree to do so.
Bug: 26097626
Change-Id: I8411b37d7f771ed99269751a3007dff103083552
This makes signapk align uncompressed .so entries to memory page
boundary (4096 bytes) to enable such libraries to be loaded at runtime
through memory-mapping the APK.
With this change in place, there should no longer be a need to run
zipalign after (or before) signapk.
Bug: 25794543
Change-Id: I74775af15a683791f57fcbd3497a79951b3f63a1
When signapk.jar is invoked by scripts like
sign_target_files_apks.py, there is no console as signapk is
invoked using popen(). To support signing of APKs using
software keys with passwords, we need to read
the password from stdin if there is no console.
Change-Id: Icf69ba1e58bf1f91979eaf1d3b91cb202782e8fd
Signed-off-by: adattatr <anisha.dattatraya.kulkarni@intel.com>
Signed-off-by: Brad Geltz <brad.geltz@intel.com>
Reads the password through console instead of stdin directly and returns it as a string.
Change-Id: I52e525680b93e9729158f4902b22f985245dbf2f
Signed-off-by: zhang jun <jun.zhang@intel.com>
Signed-off-by: Mingwei Shi <mingwei.shi@intel.com>
When signing an APK, make the SignApk tool align the stored entries to
(by default) 4-byte boundaries. This obviates the need to run the
separate zipalign tool, which currently does this job.
The alignment byte count can be specified with the -a option. OTA
package signing (with -w) never does alignment.
The order of files in the output APK is changed so that all stored
files come first in the output, followed by all non-stored files.
This is not expected to have any impact in practice.
Change-Id: Iaeef89b2a7283e25fadb99c0a0f0641f682d76b8
For supporting loading a custom key type provider, add a -providerClass
argument that loads the selected JCE at the front of the provider list.
Change-Id: I3df16f7c570d36e08806b614d6f30c41cb117565
The PKCS#8 PrivateKeyInfo structure has the algorithm OID encoded right
before the actual key octet stream is encoded. Use Bouncycastle to read
the OID for creation with the key factory.
This aids in the creation of custom key types that are backed by
hardware devices (e.g., HSMs) and have their own assigned OIDs.
Change-Id: If5d8fe07bc157e9bb5a3fb5f99091e924143105f
Remove use of the private sun.security.* classes for generating pkcs7
signatures and use bouncy castle instead.
Change-Id: Ie8213575461975085d119e000e764d2a28c26715
Change to the default compression level instead of the max compression
level for OTA packages (-w): it's much faster and the difference in
output size is usually negligible.
Bug: 6778962
Change-Id: I82a6acc19be8b3289fd84c8c15f03ebeb7a1ce63
When signing a file with -w (ie, an OTA package), add the file
META-INF/com/android/otacert, which is a copy of the public key
certificate. While this can be extracted from the CERT.RSA file,
having a copy of it more easily accessible makes it easier to write
tools.
Bug: 6477365
Change-Id: I8cdb19536eca9a223c2b954e3f8ea0d9f3f86f02
The java.util.jar implementation through Android 1.6 has a
bug where if the signature file in META-INF is a multiple
of 1024 bytes, it will throw an IOException attempting to
read it.
If signapk would produce a CERT.SF in a multiple of 1024
bytes, add an extra CRLF to the end of the file.
Bug: 3019677
Change-Id: I23d4a36e12e224be600d3ac39379b5b5a022a628
(Actually there was a tapas command that just called choosecombo).
The new better tapas command is for building unbundled apps. Run
it with one or more modules to build and optionally a build variant.
tapas [variant] App1 App2 ...
If you don't supply a build variant, it defaults to eng.
Change-Id: I02214abd0b5ad02e364fcb024e10cf6ad17a9e68
The two 0xff bytes were intended to easily distinguish files with
whole file signatures from those without, but I got the endianness
backwards. Go ahead and fix that, as long as I'm making changes to
the verifier anyway.
Check for a signature that includes the sequence 0x50 0x4b 0x05 0x06,
which looks to minzip like the start of the EOCD block.
Make SignApk generate a signature for (nearly) the entire zip file
when run with the -w option. The signature covers all of the zip file
except for the archive comment (conveniently the last thing in a zip
file); the archive comment field is used to contain the signature
itself.
SignApk fixes the timestamp of the signature files it adds. Use that
same timestamp for all the files, so that the modtime doesn't vary
from build to build. (Incremental OTAs currently spend significant
time rewriting every .apk to do nothing but patch in timestamp
changes.)
Change signapk to not propagate other signatures to the output
archive. Multiple signatures seem to confuse the package manager, as
we saw with Maps, and other partners are checking in prebuilt APKs for
google experience devices signed with random other things.
