Ok there's been some time passed and it looks like the general consensus
is to remove the password prompt feature altogether. This is the
direction I'll begin to take.
Regarding the environment variable idea, I think it may be a good
alternative to look into, but unless if there is
a demand of that feature, I won't spend time implementing it
immediately. I think the build.json will be sufficient.
Thank you everyone for your feedback.
On 2020/07/16 05:25:27, Jesse wrote:
> My suggestion would be to remove the prompt, and insist that the value>
> either come from build.json>
> and/or if we are willing to do a little more work, it could come from
an>
> env variable>
> SIGNING_PASSKEY=123123kasdj cordova build android --release>
>
> On Wed, Jul 15, 2020 at 7:08 PM Norman Breau wrote:>
>
> > 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 >
> > 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>
> >>
> >>
>
