Update signing process for Android

androideveloper commented 4 years ago

We are trying to build release version of the app, using our release key, but it get "jarsigner error: java.security.SignatureException: private key algorithm is not compatible with signature algorithm". It seems that AppCenter is using an old version of signing the app, which is security vulnerability.

As I can see from the logs AppCenter is using jarsigner and pass -sigalg MD5withRSA -digestalg SHA1, which is not secure and deprecated. I get this from the logs (Warning: The signer's certificate is self-signed. The MD5withRSA algorithm specified for the -sigalg option is considered a security risk.)

I also found these articles that confirm my idea: https://forums.xamarin.com/discussion/101114/visual-studio-build-jarsigner-algorithm

https://forums.xamarin.com/discussion/152374/why-is-the-default-algorithm-for-apk-signing-in-visual-studio-ad-hoc-still-md5

And this quote is from xamarin issue tracker https://xamarin.github.io/bugzilla-archives/57/57914/bug.html

"As of build tools 24.0.3, Google has recommended that developers use "apksigner" However we currently only support jarsigner within this task."

winnie commented 4 years ago

Thanks for the feature requets and providing the additional context. Adding @elamalani to follow up on this.

tuyen-vuduc commented 4 years ago

Hi,

I am facing the same issue.

Any updates here?

It's the standard process to set up a build.

##[section]Finishing: Build bundle from Xamarin.Android project
##[section]Starting: Sign Android App Bundle
==============================================================================
Task         : Android Signing
Description  : Sign and align Android APK files
Version      : 1.122.0
Author       : Microsoft Corporation
Help         : [More Information](https://go.microsoft.com/fwlink/?LinkID=613717)
==============================================================================
(node:2087) Warning: Use Cipheriv for counter mode of aes-256-ctr
(node:2087) Warning: Use Cipheriv for counter mode of aes-256-ctr
(node:2087) Warning: Use Cipheriv for counter mode of aes-256-ctr
(node:2087) Warning: Use Cipheriv for counter mode of aes-256-ctr
(node:2087) Warning: Use Cipheriv for counter mode of aes-256-ctr
(node:2087) Warning: Use Cipheriv for counter mode of aes-256-ctr
(node:2087) Warning: Use Cipheriv for counter mode of aes-256-ctr
(node:2087) Warning: Use Cipheriv for counter mode of aes-256-ctr
(node:2087) Warning: Use Cipheriv for counter mode of aes-256-ctr
(node:2087) Warning: Use Cipheriv for counter mode of aes-256-ctr
(node:2087) Warning: Use Cipheriv for counter mode of aes-256-ctr
[command]/usr/bin/jarsigner -keystore /Users/runner/runners/2.171.1/work/1/s/.certs/keystore.jks -storepass *** -keypass *** -verbose -sigalg SHA256withRSA -digestalg SHA-256 -signedjar /Users/runner/runners/2.171.1/work/1/s/xxxx.aab /Users/runner/runners/2.171.1/work/1/s/xxxx-Signed.aab.unsigned ***
jarsigner error: java.security.SignatureException: private key algorithm is not compatible with signature algorithm
##[error]Error: /usr/bin/jarsigner failed with return code: 1
##[error]Return code: 1

cantide5ga commented 4 years ago

Any updates or workarounds?

@winnie @elamalani

EDIT I'll try my luck with support because I feel like this is a bug, not a feature request. Removing -sigalg and -digestalg options from the jarsigner as suggested in OP seems like the way to go.

There might be some security implications that I'm not thinking of, but without explicitly setting these the default behavior is based on the algorithm used when originally generating the key.

King-of-Spades commented 4 years ago

Hi, I'm asking our product group if they can take another look at this to see if it's correctly classified as a feature request, or if it should be converted to a bug.

Tracking ID - AzDO 82591

King-of-Spades commented 4 years ago

~Unfortunately our product group has determined that this should still be treated as a feature request for the following reasons~

~The limitation isn't a change/regression on our side.~
~The work required for the upgrade is relatively larger than a typical bug fix would be.~
~There are only a small amount of upvotes on this so far.~

~It seems like the most likely scenario for this to be escalated is if more votes are received.~

Edit per the current work on this. Tracking ID - AzDO 83446

MouthOfMadness commented 4 years ago

@King-of-Spades Security exploits should be a higher priority, there might not be many upvotes because it's a simple information text in the task and not flagged as a warning or error text.

From the task:

Warning: The signer's certificate is self-signed. The MD5withRSA algorithm specified for the -sigalg option is considered a security risk

cantide5ga commented 4 years ago

I also want to highlight that I think there are two aspects to this. The security aspect should be enough to take this on, but for my team (and what I'm guessing is blocking in @tuyen-vuduc 's comment) the options for signing are causing problems for those builds that use an upload key that don't use those algorithms.

Only mentioning because I took the problem to support and they kept circling back on this Github issue. FWIW one thing we considered was owning the building step on our own CI/CD with more secure tooling and configuration, using App Center mostly for automated distribution.

Ultimately we've moved on from App Center due to lack of workarounds on either aspect.

rkops-bd commented 4 years ago

Any information when this will be fixed in AppCenter?

Bloodyairtimer commented 4 years ago

As of Android 11 it's mandatory to use the APK signer (If you use the 30 SDK) as it will set some extra schemes "APK Signature Scheme v2 now required" https://developer.android.com/about/versions/11/behavior-changes-11#minimum-signature-scheme

As for public apps this won't be a problem if you upload the AAB to the Google Play Store, but for apps that will be distributed via AppCenter or any other environment (Mobile Iron, etc.) this won't work.

I tried to do some resigning after the Android build (post-buildscript) but it seems that the variables are not available with the keystore alias, user & password. Is that correct?

From my perspective this issue should get some more attention as right now we are forced to stay on the Android 29 sdk and is this currently delaying our app improvements. (And no, i won't resign 30+ apps manually :) )

chrisstaley commented 4 years ago

@Bloodyairtimer Agreed. This is going to become a much bigger issue in the coming weeks as more and more folks begin moving to Android 11.

@King-of-Spades, let's get this knocked out. The MSBuild properties for this were released a year ago. It's time AppCenter honored them.

kvmw commented 4 years ago

given that Android 11 is already released, above fix is urgent need for those who need to support android 11. otherwise users with Android 11 won't be able to use appcenter to install apps.

anhvun commented 4 years ago

Also can replicate this issue, after testing creating a barebones android application with kotlin via android studio. If built with v2 APK signed on local on machine, and then uploading it to appcenter by creating a new release, app installs and runs on both android 11 and android 10 devices succesfully. (Because it was signed with v2 locally)

However when trying to build and sign the app through appcenter (same signature file, same credentials) (from same code from same repo), and then trying to install the app to both android 11 and android 10 devices from appcenter, on android 11 it fails. The error in the background is something like: com.android.server.pm.PackageManagerException: No signature found in package of version 2 or newer for package com.test.testandroidapp.

winnie commented 4 years ago

Hey all - apologies for the delay. Our team is actively looking into this. We'll get back to you as soon as we have an estimated target date.

pmahend1 commented 4 years ago

@winnie Android 11 has been released , we developers need to support distribution of the apps. Since we rely on AppCenter for that , when we don't have the fix available it leaves us questioning why there is no solution provided. It should take less than couple of days to make this change and may be few days for testing and then release. We still haven't heard even when this will be addressed. All this makes me feel should I have just relied on Azure DevOps pipelines .

The solution is straight forward.

Build the Android App as it was from MsBuild
Download latest bundle tool from github
Sign the build file apk/aab with the bundletool just downloaded.
It will produce a archive file with .apks extension.
Unzip the archive
pick the *.apk file and distribute with the appcenter API( release notes , build version tasks all being as-is)

I was able to do this from pipeline but the version number doesn't change , it always remains same. That is a whole different issue.

If you at least give us an approximate ETA then we will be in place to understand how long we will have to rely on alternatives.

Bloodyairtimer commented 3 years ago

@winnie it's been 3 weeks without any update. Is there any ETD to share?

MouthOfMadness commented 3 years ago

@Bloodyairtimer I had the same problem with my apk not working in appcenter and I couldn't make the new jar files work in a pipeline. So here's what I did to work around the problem. After I signed the apk file, I had to run the zipalign tool as an additional task, this is what my yaml looks like.

task: AndroidSigning@2 displayName: "align and sign"
inputs: apkFiles: '$(outputDirectory)/*.apk'
jarsign: true
jarsignerKeystoreFile: 'mykey.keystore' jarsignerKeystorePassword: '$(keystorePassword)' jarsignerKeystoreAlias: 'myalias' jarsignerKeyPassword: '$(keyPassword)' zipalign: true

ADD THIS TASK

task: CmdLine@2 displayName: "zipalign' inputs:
workingDirectory: $(outputDirectory) script: |
"C:/Program Files (x86)/Android/android-sdk/build-tools/29.0.2/zipalign.exe" -p 4 input.apk output.apk

I chose the build tool version 29.0.2 arbitrarily, there are many versions to choose from and you'll need to decide which version is best for your application.

It should be noted that this is a DevOps pipeline.

SangI762 commented 3 years ago

I have this issue too. Our QA with Android 11 can't install apk anymore since we targeting Android API 30. This should be fixed asap.

MouthOfMadness commented 3 years ago

@ignasbagdonas we upgraded to api 29 and experienced the issue on app center but adding the zipalign.exe task fixed that, you'll probably want to use build-tools/30.x.x.

This isn't an appcenter issue, we had the same problem from our build's artifact folder. The funny part, is it works correctly from the internal test track of the google play store. I speculate that they're running the zipalign command on the play store.

SangI762 commented 3 years ago

@MouthOfMadness I'm using Xamarin Android project. There is nothing what I can change. Build configuration in AppCenter is pretty simple, sign build or not. That's it.

MouthOfMadness commented 3 years ago

@ignasbagdonas We're using the xamarin android/ios project and I haven't used appcenter as a build mechanism so I'm not familiar with it's pipeline abilities. The zipalign came after we signed it. I recall reading that if you use the jarsigner, then use the zipalign after it's signed; if your you using the apksigner, then run zipalign first followed by the apksigner.

After you build it, download it and try running the zipalign from your desktop's cmd prompt, that's how we first solved it.

pmahend1 commented 3 years ago

ZipAlign is not needed, neither the use of previous version of build tools. Use the steps I have mentioned above.

MouthOfMadness commented 3 years ago

@pmahend1 are you referring to these steps? https://github.com/google/bundletool/releases

it wasn't clear to me how I could incorporate this into a devops yaml build

SangI762 commented 3 years ago

@pmahend1 We're paying for AppCenter subscription. Doing 5-15 builds a day. I don't want any manual work here. It should go as it is.

pmahend1 commented 3 years ago

@ignasbagdonas We are also paying but AppCenter team is reluctant to solve this ASAP. I was told they don't have ETA for this as they are working on stabilizing AppCenter and this is feature request. Hence I ended up creating Azure pipeline, that took less than a day.

This might have been a feature request when the issue was raised. Not anymore. This should be termed as major bug now that we have Android 11.

@MouthOfMadness

After the Android build add these steps

Download bundletool Invoke-WebRequest -Uri "https://github.com/google/bundletool/releases/download/1.3.0/bundletool-all-1.3.0.jar" -OutFile bundletool.jar

Then sign APK as mentioned here https://developer.android.com/studio/command-line/bundletool

java -jar bundletool.jar build-apks --bundle=/MyApp/my_app.aab --output=/MyApp/my_app.apks --ks=/MyApp/keystore.jks --ks-pass=pass:KeyStore_Password --ks-key-alias=MyKeyAlias --key-pass=pass:Key_Password --mode=universal

Then unzip this .

Expand-Archive -LiteralPath "path-of-apks-file" -DestinationPath "give-path"

Extracted contents will have file named universal.apk

Use AppCenter release task to publish it through AppCenter.

I had referred this : https://www.geekdashboard.com/extract-apk-files-from-aab/

I just found someone has blog as an alternative with slightly different steps https://damienaicheh.github.io/xamarin/azure/devops/2020/05/05/universal-apk-from-aab-with-azure-devops-en.html

King-of-Spades commented 3 years ago

Hi, I have a quick update that it looks like didn't get passed along as early as it should have. The current timeline for this to be released is end of this month (November 2020).

I don't know at this time if that estimate is likely to move up, stay the same, or get pushed back. I have highlighted your feedback internally though, sorry for the long wait and frustration here.

johanlunds commented 3 years ago

A workaround that worked for me was removing the keystore file from AppCenter and using these settings:

And:

android {
    signingConfigs {
        releaseSigningConfig {
            storeFile rootProject.file("app/testapp.jks")
            storePassword System.getProperty("APPCENTER_KEYSTORE_PASSWORD")
            keyAlias System.getProperty("APPCENTER_KEY_ALIAS")
            keyPassword System.getProperty("APPCENTER_KEY_PASSWORD")
        }
    }

    buildTypes {
        release {
            signingConfig signingConfigs.releaseSigningConfig
        }
    }
}

elkinjosetm commented 3 years ago

A workaround that worked for me was removing the keystore file from AppCenter and using these settings:

And:

android {
    signingConfigs {
        releaseSigningConfig {
            storeFile rootProject.file("app/testapp.jks")
            storePassword System.getProperty("APPCENTER_KEYSTORE_PASSWORD")
            keyAlias System.getProperty("APPCENTER_KEY_ALIAS")
            keyPassword System.getProperty("APPCENTER_KEY_PASSWORD")
        }
    }

    buildTypes {
        release {
            signingConfig signingConfigs.releaseSigningConfig
        }
    }
}

This workaround means the Keystore needs to be included/shared in the repository of the project, which is not precisely a good thing to do, because it's basically the "password" for you to sign your personal app for the Google PlayStore.

Personally I prefer to upload the build manually to AppCenter, like I've been doing while AppCenter update the signing process. I'm aware that it won't apply for every team/project that might have multiple apps in AppCenter.

elkinjosetm commented 3 years ago

Unless AppCenter provide a way to also make the Keystore available as an ENV variable or something in compile time, like it happen with the keystore_password and the alias. 🤔

King-of-Spades commented 3 years ago

I got an update this morning from the product team. The basic feature has been created but they're still working on final testing and backwards compatibility.

Current ETA is next week. Unfortunately, that means it's already going to miss our prior target (end of November, e.g. today). I still can't predict with complete certainty but since there's less to finish I suspect further delays would be smaller if they even occur.

elkinjosetm commented 3 years ago

@King-of-Spades What's the current ETA for the fix?

King-of-Spades commented 3 years ago

@elkinjosetm Thanks for asking, the filed issue is currently labeled with a target date for today, but as it's not out yet I'm assuming there's still some delay. I left a message asking if there's a fresh ETA and if there's any other details I can provide for you folks.

I'm setting a reminder beginning of next week to ping internally directly on that. I'd love to see this out yesterday.

King-of-Spades commented 3 years ago

ETA has been moved to this Friday, the 18th, though I'm not seeing any other details yet.

craiglp commented 3 years ago

Banner now appearing on build screens:

We now support APK Signature Scheme v2. Re-upload your keystore file to activate it.

King-of-Spades commented 3 years ago

@craiglp Yup! The feature is active as of ~12:46 PM UTC, about 3 hours ago.

elkinjosetm commented 3 years ago

Yes, I just confirm it's working for me now. Thanks you!

tobiasfrantsen commented 3 years ago

When I try to upload the keystore again on Appcenter I got this error:

Verification FAILED

[error]Error: The process '/Users/runner/Library/Android/sdk/build-tools/30.0.3/zipalign' failed with exit code 1

Others who experience it?

King-of-Spades commented 3 years ago

Verification FAILED

[error]Error: The process '/Users/runner/Library/Android/sdk/build-tools/30.0.3/zipalign' failed with exit code 1

@tobiasfrantsen I haven't seen that one in my recent tests. I even tried intentionally breaking the signing in a few ways but also couldn't figure out how to reproduce it. It looks like there's a couple support tickets our team is looking at internally, that are also correlated with the timing of this release. I haven't seen a solution there yet, but they can be reached by logging into App Center and selecting ? > Contact Support

There is an old issue with that error message here: https://github.com/microsoft/azure-pipelines-tasks/issues/10574, it was closed back on May 8th. However, a quick skim of the details...it's not clear to me if the devs who encountered the error isolated the cause to a single behavior.

If you do open a support ticket, some quick details I'd recommend providing:

Was the build previously working (for non-Android 11)?
Did you make any setting changes besides the signing update?
Does it work locally / other troubleshooting from this guide: https://docs.microsoft.com/en-us/appcenter/build/troubleshooting/build-failed
A link to the affected build, and comparison builds if some work or used to work.

JulianEzequiel commented 3 years ago

Having the same issue here! Since yesterday, I re-upload my Keystore (as AppCenter suggests) and the builds are failing.

hannta commented 3 years ago

Im also affected. No code changes, just re-uploaded keystore and now the build is failing with zipalign error.

kyhemant19 commented 3 years ago

facing same issue, just re uploaded keystrore, but facing build failed with zipalign error. Verification FAILED

[error]Error: The process '/Users/runner/Library/Android/sdk/build-tools/30.0.3/zipalign' failed with exit code 1

logicallayer commented 3 years ago

I'm having same issue, out of nowhere build stopped building since that v2 message popped out.

Reported the issue few days ago, authorized to run in debug mode but haven't heard back since.

Hopefully it gets fixed soon caused a lot of pain thinking it was an issue on our side.

Verification FAILED
##[error]Error: The process '/Users/runner/Library/Android/sdk/build-tools/30.0.3/zipalign' failed with exit code 1

miroslavmatovic commented 3 years ago

Can you please provide more specifics of your apps and build configurations where this issue occurs, so that we can test those scenarios? (e.g. platform, build configuration, like is it bundle etc., or appId)

kyhemant19 commented 3 years ago

Platform- Kotlin Build config- compile sdk version-30, build tools version 30.0.3 Min sdk version-23 Target sdk version-30 appid-cd1ca6b5-424f-4d13-875e-37d93276fa44 On Mon, 21 Dec, 2020, 3:28 pm miroslavmatovic, notifications@github.com wrote:

Can you please provide more specifics of your apps and build configurations where this issue occurs, so that we can test those scenarios? (e.g. platform, build configuration, like is it bundle etc., or appId)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/microsoft/appcenter/issues/1738#issuecomment-748884732, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN6RDBHUPRLMUPHBTJBXHUDSV4L2TANCNFSM4LEYZGSA .

JulianEzequiel commented 3 years ago

Same config as kyhemant19 here.

azakharenka1 commented 3 years ago

Got same issue with '/Users/runner/Library/Android/sdk/build-tools/30.0.3/zipalign' failed with exit code 1 Reproduced it locally - as a temp fix you could run zipalign command 2 times:

/Users/alex/Library/Android/sdk/build-tools/30.0.3/zipalign -v 4 /Users/alex/nofo-android/app/build/outputs/apk/dev/app-dev-unsigned.apk /Users/alex/nofo-android/app/build/outputs/apk/dev/app-temp.apk fail here And /Users/alex/Library/Android/sdk/build-tools/30.0.3/zipalign -v 4 /Users/alex/nofo-android/app/build/outputs/apk/dev/app-temp.apk /Users/alex/nofo-android/app/build/outputs/apk/dev/app.apk Success

miroslavmatovic commented 3 years ago

@kyhemant19, @JulianEzequiel , @logicallayer I was experimenting with configuring Kotlin app and discovered that this error happens when using gradle plugin version 4.1.0+ (in your app's build.gradle file). If you can set version to 4.0.0, this zipalign error shouldn't happen. Can you try and see if it helps?

dependencies {
        classpath "com.android.tools.build:gradle:4.0.0"
    }

kyhemant19 commented 3 years ago

thanks for the resolution, its working with dependencies { classpath "com.android.tools.build:gradle:4.0.0" } but when can we except this issue to be fixed so that we can use latest gradle.

JulianEzequiel commented 3 years ago

It's working here too. But, as kyhemant19 mentioned, it will be good if we know why and when this will be fixed. Thanks!!

logicallayer commented 3 years ago

This isn't good workaround for us as it created dataBinding error when we changed the version to 4.0.0

Any other workarounds?

pmahend1 commented 3 years ago

I am guessing if AppCenter is calling zipalign after running apksigner. Per the documentation it has to be called on unsigned apk not signed one. if jarsigner is used then zipalign comes after running jarsigner i.e. on signed apk. it would be helpful if we get implementation code of new AppCenter pipeline and the stack trace for of the error.

microsoft / appcenter