| 9f00d71787774bf79d4b398c28630f670765b791 |
|
02-Dec-2016 |
Tobias Thierer <tobiast@google.com> |
Migrate StrictJarVerifier and ShortcutPackageInfo to java.util.Base64
Previously, they weres using libcore.io.Base64, which is @deprecated.
The two implementations' encoders produce the exact same result.
The two implementations' decoders' behavior differs for malformed
input:
- In case of error, libcore.io.Base64.decode() returns null while
java.util.Base64.getDecoder().decode() throws.
- java.util.Base64 tends to be stricter about rejecting malformed
input; specifically, it allows neither whitespace nor unexpected
'=' characters (should only occur in the padding) whereas
libcore.io.Base64.decode() leniently allows them throughout the
input.
- if the input terminates prematurely, libcore.io.Base64 tends to
return fewer bytes (stops at a four byte boundary).
The behavior differences for malformed Base64 encoded data should
not affect ShortcutPackageInfo because it should only need to deal
with XML attribute values written by itself, which are well-formed.
Note that this CL does not lead to any known changes of the encoding
step, so values written by earlier versions should not cause problems
when read by later versions of ShortcutPackageInfo.
StrictJarVerifier may now reject or behave differently for .jar /
.zip files with malformed attribute values but this seems okay since,
per its name, it is meant to be strict. For example, after this CL,
StrictJarVerifier will no longer accept algorithm + "-Digest"
attribute values with extra whitespace or padding characters as valid.
Test: Confirmed that the two implementations' encoders produce the
same result by running the following code just before this CL:
assertEquals(
libcore.io.Base64.encode(allBytes()),
Base64.getEncoder().encodeToString(allBytes()));
where allBytes() returns a byte[] with values (byte) 0 .. (byte) 255
Test: Test that phone still boots after flashing code that includes
this CL.
Test: CtsLibcoreTestCases
Bug: 31292683
Change-Id: I775d32f329f693514a8f14d87e1ef0d7a757e6c3
/frameworks/base/core/java/android/util/jar/StrictJarVerifier.java
|
| 29045203f3f694cddea7b3f115ea82f648ba0cba |
|
01-Jun-2016 |
Alex Klyubin <klyubin@google.com> |
Use correct cert chain from PKCS#7 SignedData block.
This fixes a bug where APK JAR signature verifier returned the wrong
certificate chain. Rather than returning the cert chain of the
verified SignerInfo, it was returning the bag of certs of the PKCS#7
SignedData block.
This issue was introduced in Android N and thus does not affect
earlier Android platform versions.
Bug: 29055836
Change-Id: I684c0f8e9ff47b922030645e07b6a114c0eb0963
/frameworks/base/core/java/android/util/jar/StrictJarVerifier.java
|
| 9b59bc459b4cb5415909641bd1e981100bfafb2b |
|
24-Mar-2016 |
Alex Klyubin <klyubin@google.com> |
Ignore signature stripping protection for preinstalled APKs.
The current build process may currently strip APK Signature Scheme v2
signatures from prebuilt APKs to be installed on the system or vendor
partitions. However, it leaves intact the signature scheme rollback
protections introduced by APK Signature Scheme v2. Due to a bug, when
the system extracts signer certificates from preinstalled APKs, it
encounters the rollback protection and aborts the extraction process.
This manifests itself as some preinstalled packages not appearing as
installed.
This change makes the system ignore signature scheme rollback
protections when extracting certificates from preinstalled APKs. This
is fine because the process of extracting certificates from
preinstalled APKs does not care about validity/integrity of signatures
and the APKs. It only cares about extracting signer certificates.
Bug: 27829513
Change-Id: I3bed463e776b057e93a0fce915db4014946be1f9
/frameworks/base/core/java/android/util/jar/StrictJarVerifier.java
|
| e415718502897a4e5385af47d3bbe8c8257c2e5d |
|
05-Jan-2016 |
Alex Klyubin <klyubin@google.com> |
Verify APKs using APK Signature Scheme v2.
This makes Package Manager check whether an APK is signed using APK
Signature Scheme v2 and, if it is, verify the APK's signatures using
that scheme rather than the usual JAR signature scheme.
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: If59fe013f2e62bac7677bb20e65f6061b91eec2e
/frameworks/base/core/java/android/util/jar/StrictJarVerifier.java
|
| 8a7c1606d88873c5a1b5764c16cb046b6f2275b2 |
|
03-Nov-2015 |
Przemyslaw Szczepaniak <pszczepaniak@google.com> |
Move StrictJarFile from libcore to framework
Bug: 25337946
Change-Id: Ib4fac6fa9f534b8654e5ca158bbaedb2393772ba
(cherrypicked from 43ea2cc2a81926a6b2ca13d41f4eab089640129e)
/frameworks/base/core/java/android/util/jar/StrictJarVerifier.java
|