Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/mobile: gomobile should sign with debug.keystore if exists #10090

Closed
rakyll opened this issue Mar 5, 2015 · 9 comments
Closed

x/mobile: gomobile should sign with debug.keystore if exists #10090

rakyll opened this issue Mar 5, 2015 · 9 comments

Comments

@rakyll
Copy link
Contributor

rakyll commented Mar 5, 2015

The apks should be signed with ~/.android/debug.keystore rather than the embedded certificate. We can fallback to the embedded certificate if there is no debug.keystore.

@rakyll rakyll self-assigned this Mar 5, 2015
@crawshaw
Copy link
Member

crawshaw commented Mar 6, 2015

FYI, debug.keystore is in an undocumented Java format. There's a note here about it: https://github.com/golang/mobile/blob/master/cmd/gomobile/writer.go#L56

@rakyll
Copy link
Contributor Author

rakyll commented Apr 8, 2015

Why don't we shell out to keytool if user has SDK installed on their machine? If keytool is not on the PATH, we can fallback to the hardcoded key.

cc/ @hyangah

@crawshaw
Copy link
Member

crawshaw commented Apr 8, 2015

I have found the Android SDK does not put itself on the PATH, nor encourage users to set other environment variables. IDE-based projects expect to be used from inside IDEs. So how do you intend to find the tools on the average user's machine?

That said, keytool I believe is part of the JVM, not the Android SDK. It may well be common on the PATH of people with the SDK installed. (Or it may be inferable from some common Java environment variable.) So using it might well work, it just needs to be tried on a relatively light SDK setup.

@rakyll
Copy link
Contributor Author

rakyll commented Apr 8, 2015

keytool is a part of JDK. None of these details conflicts with my idea to fallback to the embedded key if we can't shell out and export. I would consider this as a workaround, we may recommend the user to have keytool in their PATH for debug.keystore support.

@crawshaw
Copy link
Member

crawshaw commented Apr 8, 2015

I'm OK with it if it is generally useful in the usual cases. That is, does the default install of Android Studio put keytool on the path on OS X, Linux, and Windows? Two out of three would be useful enough. If zero, it's not worthwhile. It's an empirical question.

@hyangah
Copy link
Contributor

hyangah commented Apr 8, 2015

I don't think Android Studio does anything with installation of keytool,
but Android Studio requires JDK, and JDK installation seems to place the
keytool in an easily discoverable place (e.g. /usr/bin in my case). The
default install of ubuntu doesn't seem to have it, but after apt-getting
open-jdk, i found it in /usr/bin. Given that the installation is not
painful, I think documentation mentioning the keytool is sufficient and
relying on keytool is okay.

2015-04-07 22:21 GMT-04:00 David Crawshaw notifications@github.com:

I'm OK with it if it is generally useful in the usual cases. That is, does
the default install of Android Studio put keytool on the path on OS X,
Linux, and Windows? Two out of three would be useful enough. If zero, it's
not worthwhile. It's an empirical question.


Reply to this email directly or view it on GitHub
#10090 (comment).

__

@crawshaw
Copy link
Member

crawshaw commented Apr 8, 2015

At what point in the documentation would this be mentioned? I'm trying to avoid "first, install java" as a development requirement for all-Go apps. (Because it will have to be followed with "second, uninstall the Ask toolbar".)

@rakyll
Copy link
Contributor Author

rakyll commented Apr 8, 2015

It should be mentioned in the lines of "if you already have a debug.keystore, we will use it" which already indicates that they have keytool on their machine. debug.keystore is generated by keytool. JDK is not a hard requirement, we will fallback to the embedded key.

You may argue that we should restrict the tool to the PEM keys. Apple distributes certificates as p12, the users will similarly need to convert them to PEM.

@rakyll
Copy link
Contributor Author

rakyll commented Apr 9, 2015

I am closing this issue in the favor of using a dummy key for development. We will introduce a flag to provide a PEM file for release builds. Or we might ask to user to provide the key from a known location such as ~/.gomobile/android.pem.

Both strategies seems to be applicable to the iOS release builds.

@rakyll rakyll closed this as completed Apr 9, 2015
@mikioh mikioh changed the title mobile: gomobile should sign with debug.keystore if exists x/mobile: gomobile should sign with debug.keystore if exists Aug 5, 2015
@golang golang locked and limited conversation to collaborators Aug 5, 2016
@rsc rsc unassigned rakyll Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants