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 > >
