GTS fail之GtsPackageSignatureTest和GtsApexSignatureVerificationTest

目录

1. Fail项具体详情

2. Google为何增加测试项

3. 解决方法

---

1. Fail项具体详情

run gts -m GtsPackageSignatureTest -t android.security.cts.PackageSignatureTest#testPackageSignatures fail

Test	Result	Details
android.security.cts.PackageSignatureTest#testPackageSignatures	fail	junit.framework.AssertionFailedError: These packages should not be signed with a well known key: [com.android.hotspot2.osulogin, com.android.wifi.resources]arm64-v8a GtsPackageSignatureTest

run gts -m GtsApexSignatureVerificationTest -t android.appsecurity.cts.ApexSignatureVerificationTest#testApexPubKeyIsNotWellKnownKey

arm64-v8a GtsApexSignatureVerificationTest
Test	Result	Details
android.appsecurity.cts.ApexSignatureVerificationTest#testApexPubKeyIsNotWellKnownKey	fail	3 expectations failed: 1. com.android.vndk.v31 must not use well known pubkey expected to be false at android.appsecurity.cts.ApexSignatureVerificationTest.testApexPubKeyIsNotWellKnownKey(ApexSignatureVerificationTest.java:158) 2. com.android.appsearch must not use well known pubkey expected to be false ... 1 more 3. com.android.wifi must not use well known pubkey expected to be false ... 1 more

从case的名称上来看，两类case都是针对Apex(Android pony express)做的针对性测试，而且从字面上来看都是需要加强对签名Key的强化，而且第二类ApexPubKey其实有点眼熟，之前CTS有处理过类似的问题，具体可参考之前记录的该篇Cts 失败项之CtsAppSecurityHostTestCases-CSDN博客，本文简单梳理下GtsPackageSignatureTest。

2. Google为何增加测试项

为什么Google会增加case来强制让我们更新Apex的sign key呢，不明真相的我们可能会觉得多此一举，个人最初也会有类似的感受，但直到我查了下GTS的release notes，就觉得还是需要重视sign key的，原来是CVE漏洞的需要，这里也没有能力对CVE展开，就贴一下供大家参考，有Google partner账号的，可以继续对漏洞做进一步的了解，这里我就不瞎带路了。

3. 解决方法

因为GtsApexSignatureVerificationTest处理方案就是重新给对用的apex生成相应的avb pub key， 只要参考Cts 失败项之CtsAppSecurityHostTestCases-CSDN博客， 

直接说下GtsPackageSignatureTest的签名问题，打开com.android.hotspot2.osulogin, com.android.wifi.resources对应的bp

以com.android.hotspot2.osulogin为例，Android.bp的内容如下：

android_app {
    name: "OsuLogin",
    defaults: ["wifi-module-sdk-version-defaults"],
    static_libs: ["androidx.legacy_legacy-support-v4"],
    resource_dirs: ["res"],
    srcs: ["src/**/*.java"],
    sdk_version: "system_current",
//把默认的签名修改为platform签名
-   certificate: ":com.android.hotspot2.osulogin.certificate",
+   certificate: "platform",  
    apex_available: [
        "com.android.wifi",
        "test_com.android.wifi",
    ],
}

android_app_certificate {
    name: "com.android.hotspot2.osulogin.certificate",
    certificate: "certs/com.android.hotspot2.osulogin"
}

这里提一个快速验证是否生效的办法，编译完OS检查OTA target_file的META目录下apexkeys.txt文件中对应的Apex package的签名是否有带platform签名的路径即可，随便举例类似：

name="com.android.cellbroadcast.apex" public_key="packages/apps/CellBroadcastReceiver/apex/com.android.cellbroadcast.avbpubkey" private_key="packages/apps/CellBroadcastReceiver/apex/com.android.cellbroadcast.pem" container_certificate="build/make/xx/xxx/releasekey.x509.pem" container_private_key="build/make/xx/xxx/releasekey.pk8" partition="system_ext"

以上自己做个记录，也分享给遇到这个问题朋友。