Why is Bromite Webview changing package name to org.bromite.webview?

[ghost]

And what would happen to the people who installed Bromite Webview under package name com.android.webview?

[Disqu3-mirOir-qt]

package not change i just downloaded latest

[csagan5]

The current package name is not correct. The new one would allow installation of multiple webviews.

[realdmitchell]

As a (novice) custom rom builder (of lineage) I usually replace webview.apk in the repo https://github.com/LineageOS/android_external_chromium-webview/tree/master/prebuilt/arm64
and build the ROM.

Now with changed package name. I assume I should add to the allowlist
org.bromite.webview
inside the file

https://github.com/LineageOS/android_vendor_lineage/blob/lineage-18.1/overlay/common/frameworks/base/core/res/res/xml/config_webview_packages.xml

If yes, could you please tell me what is the value for <signature>

Many thanks... Your work is appreciated.

[csagan5]

You can get the signature with a command like this:

unzip -p SystemWebView.apk META-INF/BROMITEK.RSA | openssl pkcs7 -in - -inform DER -print_certs

When you join all base64 pieces you get:

MIIDbTCCAlWgAwIBAgIEHcsmjjANBgkqhkiG9w0BAQsFADBmMQswCQYDVQQGEwJERTEQMA4GA1UECBMHVW5rbm93bjEPMA0GA1UEBxMGQmVybGluMRAwDgYDVQQKEwdCcm9taXRlMRAwDgYDVQQLEwdCcm9taXRlMRAwDgYDVQQDEwdjc2FnYW41MCAXDTE4MDExOTA3MjE1N1oYDzIwNjgwMTA3MDcyMTU3WjBmMQswCQYDVQQGEwJERTEQMA4GA1UECBMHVW5rbm93bjEPMA0GA1UEBxMGQmVybGluMRAwDgYDVQQKEwdCcm9taXRlMRAwDgYDVQQLEwdCcm9taXRlMRAwDgYDVQQDEwdjc2FnYW41MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtakjGj0eTavbBB2vWXj8KBixWn4zgXAKc+yGFu3SLEGF1VB5aJWwcMHxVI55yH/8M2eNnJP0BkSidfKgPVcm1sk/GrNEs9uk5sWod9byO5M5QWQmGP2REeTd6J0BVVVaMp2MZnqeR3Su3pwFzrSwTqIGyf8dkPSEz7ifj792+EeRNrov4oRQK7lIfqInzwc4d34wU069Lrw6m7J7HM0KbRYISsWMiYj025Qg+dTrtdWt7jbdcj7htW0eYyJoLd90+s43RWnOpENmWpcWv1EVPxUD4mCdV9idYwoHRIESpSu9IWvqDZp1VoRc43nLgsNfNBwmYdTkIaPiz1m7TBcr7QIDAQABoyEwHzAdBgNVHQ4EFgQUuWoGd7W7wMyQ1pOdjiMv10YHTR0wDQYJKoZIhvcNAQELBQADggEBAA7iw6eKz+T8HIpKDoDcX1Ywjn9JUzuCFu20LnsLzreO/Pog1xErYjdLAS7LTZokfbAnitBskO9QhV9BYkDiM0Qr5v2/HsJTtxa1mz9ywCcI36jblMyuXFj8tuwQI9/t9i+Fc3+bOFBV3t7djPo9qX1dIK0lZ6s8HcIhaCNdqm65fH+nWhC/H9djqC6qOtrkTiACKEcHQ4a/5dfROU0q0M4bS4YuiaAQWgjiGbik4LrZ8wZX1aqJCLt0Hs7MzXyyf0cRSO11FIOViHwzh6WTZGufq2J3YBFXPond8kLxkKL3LNezbi5yTcecxsbKQ6OS46CnIKcy/M8asSreLpoCDvw=

NOTE: this is the signature of the current SystemWebView (v96), it will change once v97 is released because package name is also included in the signature generation.

[csagan5]

I was wrong about the above; signature is unchanged for v97.

[ghost]

By the way, the installation wiki for webview has just been updated to: "without a signature block it will be UNSECURE". What kind of " unsecure" are you talking about here? Does this mean all of previous Bromite installations under com.android.webview package namr are unsecure?

[csagan5]

Does this mean all of previous Bromite installations under com.android.webview package name are unsecure?

Do you have Bromite SystemWebView installations without signature blocks?

[ghost]

Do you have Bromite SystemWebView installations without signature blocks

Yes, my ROM does not come preinstall with Bromite webview so i replaced the AOSP webview apk with Bromite system webview apk in TWRP, and my framework-res has com.android.webview but no signature block. How "unsecure" would this be?

[csagan5]

If your ROM comes pre-installed with a com.android.webview package then it's fine, the signature block is optional. It is not unsecure.

[realdmitchell]

unsecure

If a signature block is included in config_webview_packages.xml then only APKs with that signature can be installed with that name org.bromite.webview This is the reason, if you build your own app with package ID com.android.chrome and if the device already has a Chrome (usually with stock ROMs) it will NOT install. (as the signature is different; and google has the signature). Same applies to other apps.

With unsecure, any app can masquerade as org.bromite.webview

es this mean all of previous Bromite installations under com.android.webview package namr are unsecure?

I assumed that bromite package used the com.android.webview (i.e) AOSP build signatures

[csagan5]

Bromite APKs do not use AOSP build signatures, thus they either need to be preinstalled in the ROM or whitelisted with the correct signature.

When pre-installed in the ROM Android will prevent installing a new package with the same a different signature, so it is still secure.

[realdmitchell]

When pre-installed in the ROM Android will prevent installing a new package with the same signature, so it is still secure.

For clarity, can another package ever have same signature? I thought it would be impossible to have same signature unless the 'existing' developer's keys are available. Do I assume you mean, "it will prevent installing a new package with same name, but with different signature"
Thanks

[csagan5]

I corrected my comment; indeed it is impossible to have same signature unless the same private keys are used to sign a package.

[csagan5]

@androidacybot I noticed you maintain some unofficial automation to install the Bromite SystemWebView; see the upcoming package name change news.

[androidacy-user]

Yeah we're aware, it's just a matter of getting around to it, we should have an update in the next couple days. But thanks for the heads-up anyway

[androidacy-user]

Fixed in Androidacy/WebviewManager-Module@32e8f54

[csagan5]

Fixed in Androidacy/WebviewManager-Module@32e8f54

@androidacybot AFAIK it is unsecure to have those entries in config_webview_packages.xml without signature and without the corresponding package pre-installed.

[androidacy-user]

Fixed in Androidacy/WebviewManager-Module@32e8f54

@androidacybot AFAIK it is unsecure to have those entries in config_webview_packages.xml without signature and without the corresponding package pre-installed.

You are not incorrect, but because of the module it does come preinstalled as far as Android thinks it is, and we do intend to add signature enforcement to the overlay once we get all the time and add it to the API. That part is waiting in the backlog behind an API rewrite, however, so the pseudo preinstalled works for now.