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 <nor...@normanbreau.com> 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 <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 > >
