Keystore password prompt

[Norman Breau <no...@normanbreau.com>]

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-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org

Re: Keystore password prompt

[Jesse <pu...@gmail.com>]

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 <no...@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 <no...@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-unsubscribe@cordova.apache.org
> >> For additional commands, e-mail: dev-help@cordova.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>

Re: Keystore password prompt

[Norman Breau <no...@normanbreau.com>]

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 <no...@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-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org

Re: Keystore password prompt

[Chris Brody <ch...@gmail.com>]

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 <no...@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-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>