If we deprecate the password prompt feature and remove in the next
major, this leaves the user with the following options:
- Use build.json to have cordova sign apps for the user automatically.
- Not use build.json, which gives the user the unsigned apk, which
they'll have to sign themselves using the appropriate tools.
Using the jarsigner I know has similar features where if you don't pass
in the password fields, then they'll prompt the user. So if we really
wanted to keep the feature... I could perhaps look at removing the
signing out of gradle, then make the cordova tooling use the jarsigner
tool... which is a tool that is included with java. It may be more
reliable than gradle.
But personally I'm in favour of removing the feature altogether in the
next major.
On 2020-07-15 10:39 p.m., Chris Brody wrote:
I think we should not be making our own password-based or other secure
build tools within the Cordova project unless it is absolutely necessary.
This looks like a problem that is not unique to Cordova app development.
I think this is something that should be done by other tools such as
Gradle, Android Studio, Android command-line tool, etc.
I think it would be much safer to leave this kind of thing to underlying
tools, which have both a wider audience and are more likely to have the
right kind of expertise, than our own tooling.
In case any of us are able to make a password-based build tool that could
help others, and it could benefit our users, that would be awesome.
I would compare this to the way that Capacitor expects users to use
platform-specific IDEs to build and run on the mobile platforms.
On Wed, Jul 15, 2020 at 9:24 PM Norman Breau <nor...@normanbreau.com> wrote:
Hi Team,
Looking for some opinions on the keystore password prompt, when building
for android.
TL;DR; is this feature worth keeping?
If you're not aware, if you leave either the store password or the key
password blank/empty string inside
the build.json file, then we have a gradle implementation to prompt the
user for a password.
It was recently been discovered that it was broken.I went back several
versions of both gradle and cordova-android, but I was unable to find
when it was not broken. Some research suggest that the prompt would have
been broken since gradle 3.x.
There is two problems with the prompt. The first issue is that when
using a gradle daemon, or if you change any of the default java settings
(which we do, cause we need to set -Xmx to at least 2gb to handle
android builds with dex), then gradle will spawn a subprocess to do a
gradle build. This means gradle does not have a console attached and
cannot receive user input.
cordova-android currently will fail with "Failed to create component for
'dialog' reason: java.awt.HeadlessException"
I've created a PR that addresses this issue by making the password
prompt use a GUI, if the console is not available, which works, but
exposes the second issue. I've spent a considerable amount of time
trying to fix but I haven't been able to find a solution.
The issue is that gradle password prompts doesn't appear to work at all,
regardless if you use the GUI method, or the console input method. It
always results in a "Keystore was tampered with, or password was
incorrect".
I've observed this using my own keystore I use for apps. If I put the
password in the build.json file, it works. If I use the password prompt,
it doesn't work. I've produced logging to determine that the password
prompt is receiving the correct text as expected, and I've confirmed
that the android signingConfigs has the correct information. It's a
rather weird problem, and you can try this yourself by applying the
prompt fix PR.
I've already talked to Erisu about possible workarounds, but we
determined if we need this feature, the implementation must be kept at
the gradle level. Otherwise, you'll be introducing security
vulnerabilities.
So before I spend anymore time on this, I want to gather thoughts,
particularly if this feature is even worth keeping. It's only use case
would be for end users who prefer not to store their password on the
filesystem. Obviously it can't be use for CI or much other purposes.
Given that it's been broken for so long without complaints, I don't
think the feature is commonly used. The individual who recently brought
attention to this issue has moved to putting their pw in their
build.json as well.
Context links:
Original prompt issue:
https://github.com/apache/cordova-android/issues/1021
Prompt fix PR: https://github.com/apache/cordova-android/pull/1022
Tamper issue: https://github.com/apache/cordova-android/issues/1023
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
