New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide way to sign package/bundle with custom keyfile without writing passphrase to log #3513
Comments
@mungojam Thanks for the bug report, I will take a look at adding a couple of new MSBuild properties which will provide the In fact it might be easier to allow the user to do something like
we can then just parse those values in the task an use the correct argument. |
happy with that solution for my own use. It does rely on people not happening to start their passwords with |
Yup, if you have env: or file: in your password that would be a problem lol. |
… APKs. Fixes xamarin#3513 Both `jarsigner` and `apksigner` provide a way to use both files and environment variables for the store and key passwords. For `jarsigner` you have to suffix the parameter switch with either `:env` or `:file` to use those options. For `apksigner` you have to prefix the value with either `:env`, `:file` or `:pass`. We currently only support raw passwords. This commit adds support for using both `env:` and `file:` for signing. When providing values for the MSBuild properties such as `AndroidSigningStorePass` and `AndroidSigningKeyPass` all they need to do is prefix the value with `env:` or `file:` to use the alternative parameters. /p:AndroidSigningKeyPass=env:MyPasswordEnvVar /p:AndroidSigningKeyPass=file:PathToPasswordFile This will stop passwords appearing in build logs etc.
… APKs. Fixes xamarin#3513 Both `jarsigner` and `apksigner` provide a way to use both files and environment variables for the store and key passwords. For `jarsigner` you have to suffix the parameter switch with either `:env` or `:file` to use those options. For `apksigner` you have to prefix the value with either `:env`, `:file` or `:pass`. We currently only support raw passwords. This commit adds support for using both `env:` and `file:` for signing. When providing values for the MSBuild properties such as `AndroidSigningStorePass` and `AndroidSigningKeyPass` all they need to do is prefix the value with `env:` or `file:` to use the alternative parameters. /p:AndroidSigningKeyPass=env:MyPasswordEnvVar /p:AndroidSigningKeyPass=file:PathToPasswordFile This will stop passwords appearing in build logs etc.
… APKs. Fixes xamarin#3513 Both `jarsigner` and `apksigner` provide a way to use both files and environment variables for the store and key passwords. For `jarsigner` you have to suffix the parameter switch with either `:env` or `:file` to use those options. For `apksigner` you have to prefix the value with either `:env`, `:file` or `:pass`. We currently only support raw passwords. This commit adds support for using both `env:` and `file:` for signing. When providing values for the MSBuild properties such as `AndroidSigningStorePass` and `AndroidSigningKeyPass` all they need to do is prefix the value with `env:` or `file:` to use the alternative parameters. /p:AndroidSigningKeyPass=env:MyPasswordEnvVar /p:AndroidSigningKeyPass=file:PathToPasswordFile This will stop passwords appearing in build logs etc.
… APKs. Fixes xamarin#3513 Both `jarsigner` and `apksigner` provide a way to use both files and environment variables for the store and key passwords. For `jarsigner` you have to suffix the parameter switch with either `:env` or `:file` to use those options. For `apksigner` you have to prefix the value with either `:env`, `:file` or `:pass`. We currently only support raw passwords. This commit adds support for using both `env:` and `file:` for signing. When providing values for the MSBuild properties such as `AndroidSigningStorePass` and `AndroidSigningKeyPass` all they need to do is prefix the value with `env:` or `file:` to use the alternative parameters. /p:AndroidSigningKeyPass=env:MyPasswordEnvVar /p:AndroidSigningKeyPass=file:PathToPasswordFile This will stop passwords appearing in build logs etc.
…3522) Fixes: #3513 Both `jarsigner` and `apksigner` provide a way to use both files and environment variables for the store and key passwords. For `jarsigner` you have to suffix the parameter switch with either `:env` or `:file` to use those options. For `apksigner` you have to prefix the value with either `:env`, `:file` or `:pass`. We currently only support raw passwords. This commit adds support for using both `env:` and `file:` for signing. When providing values for the MSBuild properties such as `$(AndroidSigningStorePass)` and `$(AndroidSigningKeyPass)` all they need to do is prefix the value with `env:` or `file:` to use the alternative parameters. /p:AndroidSigningKeyPass=env:MyPasswordEnvVar /p:AndroidSigningKeyPass=file:PathToPasswordFile This will stop passwords appearing in build logs etc.
Release status update A new Preview version has now been published on Windows that includes the fix for this item. The fix is not yet included in a Release version. I will update this item again when a Release version is available that includes the fix. The fix is not yet available on macOS. I will update this item again when a Preview version with the fix is available on macOS. Fix included in Xamarin.Android 10.0.99.100. Fix included on Windows in Visual Studio 2019 version 16.4 Preview 1. To try the Preview version that includes the fix, check for the latest updates in Visual Studio Preview. Fix not yet available on macOS. |
Thanks, I actually need it for the Linux build of android which I fetch off Jenkins as part of a docker image. But that Linux build has been failing since earlier this year: |
Hey @mungojam , we are also seeking the Android.Xamarin.Linux build and just noticed it has been failing for sometime now. Have you received any communication on this? The main build looks like it is just failing to communicate to Github... https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android-linux/ |
I've not heard anything on it unfortunately |
I'll aim to raise a question with team about whether there are plans to enable the Linux continuous build job again in the future. For the moment, I'll add an update for the Windows and macOS packages. Release status update A new Release version has now been published on Windows that includes the fix for this item. The fix is not yet published in a Release version on macOS. I will update this item again when a Release version is available on macOS that includes the fix. Fix included in Xamarin.Android 10.1.0.30. Fix included on Windows in Visual Studio 2019 version 16.4. To get the new version that includes the fix, check for the latest updates or install the latest version from https://visualstudio.microsoft.com/downloads/. (Fix also included on macOS in Visual Studio 2019 for Mac version 8.4 Preview 2.1 and higher. To try the Preview version that includes the fix, check for the latest updates on the Preview updater channel.) |
Any word back on this? Thanks @brendanzagaeski |
Apologies for the slow reply. I found out that there is some work in progress to see about making .deb packages available again for more recent Xamarin.Android commits, but the timeline for availability isn't yet known. I'll stay in the loop on that work and update #2009 and #4116 when there's news. |
When I run
msbuild
with/t:SignAndroidPackage
and provide a custom keystore, the keystore and key passwords end up being written out to the build log because it logs the call made tojarsigner
/apksigner
.I wanted to prevent the passwords being written to the log, so I have ended up doing the signing as a separate step. In this step I make use of the
:env
the suffix injarsigner
or theenv:
prefix inapksigner
before I switched to bundles.Below is what my build looks like now.
AndroidSigning_StorePass
is an environment variable that I populate in a pre-build step with the password:The above seems to work fine, but it took a lot of effort to get there. It would be better if I could use the standard build target but still keep the sensitive data out of the log. Then I wouldn't need to do the custom signing and could benefit from any future tweaks that you put in the standard build target.
The text was updated successfully, but these errors were encountered: