cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frederico Galvão <frederico.gal...@pontoget.com.br>
Subject Re: Build signed archives using CLI
Date Thu, 09 Oct 2014 19:13:28 GMT
The ant target that is executed when I run "cordova build android
--release" with the appropriate .properties in place already prompts me for
the keystore passwords (there are 2). The itunes deployment done through
xCode archiver also asks for a password once.

I think prompting for passwords in the process is something we can't avoid,
unless we're brave enough to ask passwords to be stored somewhere else so
the non-interactive packaging can be done, but I might be wrong here.

Documentation on this topic has to be golden and well thought through,
above average I'd say. I can envision so much confusion and trouble if we
create this layer between the developer and the native requirements, it's
already **too hard** to get it working in iOS following the official
configuration documentation, I wonder how hard it can get when you have to
go through another tool(cordova).

2014-10-09 16:02 GMT-03:00 Shazron <shazron@gmail.com>:

> Liking Subhag's proposal.
> Agree with Jesse on using conventions as a default plus config.xml -- with
> overrides/env-vars possible. The only caveat for including info in the
> config.xml is, the config.xml data is copied into the iOS platform and will
> be included in the .app bundle, and will leak information (even though
> harmless, since it shouldn't contain passwords, etc) -- so maybe that is
> not desirable, using config.xml.
>
> We will need to provide the password each time at least for iOS, since we
> need to unlock the keychain for code signing.
>
>
>
>
>
>
>
>
> On Thu, Oct 9, 2014 at 11:25 AM, Andrew Grieve <agrieve@chromium.org>
> wrote:
>
> > The prompting is actually pretty appropriate here since passwords are
> > involved I think. I think also that keys will often not be checked into
> > source control, but maybe the best way to support that is to allow
> multiple
> > ways of specifying things (e.g. default to convention, allow override via
> > config.xml, allow override via command-line & env variable as well)
> >
> > On Thu, Oct 9, 2014 at 2:17 PM, Jesse <purplecabbage@gmail.com> wrote:
> >
> > > I am liking all of this.
> > > Are we ready to move this to an editable plaintext doc to collaborate
> on?
> > >
> > > I agree that we should take advantage of as much 'by-convention' as we
> > can,
> > > meaning things like `cordova package ios` defaults to a code sign
> > identity
> > > of 'iPhone Developer' and signs based on app-bundle-id, ...
> > >
> > > If it does not make sense as a convention, then I too would like to see
> > as
> > > much as possible done through config.xml as Fredrico points out, and
> > agree
> > > on picking the most consistent names possible.
> > >
> > > I would prefer that we do not prompt, and simply fail fast, given that
> > > tools will typically be consuming the cli.  Or we should at least
> > provide a
> > > --noPrompt option. Anything prompt-able should be config.xml-able
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > @purplecabbage
> > > risingj.com
> > >
> > > On Thu, Oct 9, 2014 at 10:48 AM, Chuck Lantz <clantz@microsoft.com>
> > wrote:
> > >
> > > > One option here could be to build off of the idea of the "res" folder
> > > that
> > > > is in the current samples for splashscreens and icons and introduce
> > > > something like "res/native".  Files placed here would be put into the
> > > > native project folders "before_prepare" and would be further enhanced
> > by
> > > > the plugin and build infrastructure.  This would allow you to place
> > > > customized native assets that are unique to your project in a place
> > that
> > > > you can check in and would be unaffected by an upgrade.
> > > >
> > > > Andrew's environment variable idea could also provide an alternate
> > means
> > > > to specify platform specific values (what Soak mentions in the { }).
> > > >
> > > > -Chuck
> > > >
> > > > -----Original Message-----
> > > > From: Frederico Galvão [mailto:frederico.galvao@pontoget.com.br]
> > > > Sent: Thursday, October 9, 2014 10:33 AM
> > > > Cc: dev@cordova.apache.org
> > > > Subject: Re: Build signed archives using CLI
> > > >
> > > > I agree with pretty much everything mentioned, but as far as I know
> > > > cordova is trying it's best to not depend on anything to be in
> > > > /platforms/<TARGET_PLATFORM>/. Having said that, the package command
> > > should
> > > > always expect things to be in config.xml or something like that.
> > > >
> > > > Also, the closer we are in naming things to what they are already
> known
> > > as
> > > > in the native platform, the better.
> > > >
> > > > 2014-10-08 20:03 GMT-03:00 Subhag Oak <Subhag.Oak@microsoft.com>:
> > > >
> > > > > Hey Cordova community,
> > > > >
> > > > >
> > > > >
> > > > > I am Subhag Oak, senior program manager on the Visual Studio team
> > > > > working on VS tools for Multi device hybrid apps. In line with the
> > > > > discussion of having a generic Cordova ‘packaging’ command for
all
> > > > > platforms, here is one
> > > > > proposal:
> > > > >
> > > > >
> > > > >
> > > > > As we all know, packaging an application for deployment requires
> > extra
> > > > > steps that are specific to the native platforms.  A new generic
> > > > > Cordova CLI ‘package’ command can perform these platform specific
> > > > > actions to generate a final signed package ready for deployment:
> > > > >
> > > > > cordova package [platform] [--packageConfiguration] {--
> > > > > –-sign[location]
> > > > > -- –-embed[location] -- --signIdentity[location]}, where all the
> > > > > parameters within { } are platform specific overrides.
> > > > >
> > > > >
> > > > >
> > > > > If no platform is specified, the command will build packages for
> all
> > > > > platforms added.
> > > > >
> > > > >
> > > > >
> > > > > The values for –packageConfiguration are interpreted by the
> > respective
> > > > > platforms. For Android and Windows, the value can be debug or
> > release,
> > > > > with release being the default value.  For iOS, the possible values
> > > > > are development, adhoc or store with development being the default
> > > > > value. The
> > > > > -- --sign, -- -- embed  and -- --signIdentity are optional iOS
> > > > > specific signing arguments for specifying the location of
> > code-signing
> > > > > certificate, the provisioning profile or the code signing identity
> > > > > (certificates along with public and private keys) respectively.
> > > > >
> > > > >
> > > > >
> > > > > e.g:
> > > > >
> > > > > ·         ‘cordova package iOS’ would generate a signed ipa
with
> > > > > development profile, using code signing identity defined in
> > > > build.xcconfig:
> > > > >
> > > > > // to list all installed iOS identities, run:
> > > > >
> > > > > // security find-identity |  sed -n 's/.*\("[^"]*"\).*/\1/p' | grep
> > > > > 'iPhone'
> > > > >
> > > > > // generic 'iPhone Developer' (no quotes) will match the right
> > > > > Identity with the right Provisioning // Profile plus Certificate,
> > > > > based on the app bundle id
> > > > >
> > > > > CODE_SIGN_IDENTITY = iPhone Developer
> > > > >
> > > > >
> > > > >
> > > > > ·         ‘cordova package android’ would generate a release
signed
> > > using
> > > > > the packaging assets (keystore, alias and password) defined in the
> > > > > ant.properties files using the ANT build. This would be using
> > > > > gradle.propoerties once cordova changes to gradle build like the
> one
> > > > > Andrew mentions below.
> > > > >
> > > > >
> > > > >
> > > > > ·         ‘Cordova package windows’ would generate a signed
APPX
> > > package.
> > > > > This will use the following tools in the Windows SDK:
> > > > >
> > > > > •                    An unsigned packaged Windows Store app, for
> > > example,
> > > > > an .APPX file created by using the app packager (MakeAppx.exe) tool
> > > > >
> > > > > •                    A valid code signing certificate, for
> example, a
> > > > > Personal Information Exchange (.pfx) file created with the
> > > > > MakeCert.exe and Pvk2Pfx.exe tools
> > > > >
> > > > > •                    SignTool, which is part of the Windows SDK
> > > > >
> > > > >
> > > > >
> > > > > Here is how the package command should work. The proposal is to
> make
> > > > > the ‘package’ command work on convention (similar to the Cordova
> > build
> > > > > command) rather than config settings. The command would look out
> for
> > > > > packaging assets in the “platform\ [native-platform]” folder.
> > > > >
> > > > >
> > > > >
> > > > > For android, the contents of the ant.properties (keystore,
> password,
> > > > > alias and alias password) would be used for packaging. If any of
> > these
> > > > > properties is missing in ant.properties [or gradle.properties for
> > > > > gradle build] or if the file is missing, the command would prompt
> the
> > > > > user for these value at the command prompt. If the values provided
> > are
> > > > > invalid, the command would fail.
> > > > >
> > > > >
> > > > >
> > > > > For iOS, the contents of build.xcconfig specify the code-sign
> > > > > certificate and the provisioning profile to be used. The default
> > > > > build.xcconfig file is setup to handle different information by
> build
> > > > > profile based on the configuration defined in the command.
> > > > > Build.xcconfig can also support signing identities that tie the
> > > > > code-sign certificate with the provisioning profile.
> > > > >
> > > > >
> > > > >
> > > > > Tools like VS and other IDEs, which use cordova CLI, may need an
> > > > > explicit way to specify certs/profile for packaging for iOS (since
> > the
> > > > > build needs to happen on MAC agent) instead of the assets being
> > > > > defined in the build.xcconfig. One way to allow this is by using
> > > > > optional platform specific arguments to the package command like:
> > > > >
> > > > > Cordova package iOS --development --sign “d:\cert\mycert.cer”
> --embed
> > > > > “d:\cert\devprovision.mobileprovisioning”
> > > > >
> > > > > This command will run the xcrun command to generate a signed IPA
> with
> > > > > development provisioning profile.
> > > > >
> > > > >
> > > > >
> > > > > I would love to hear your comments, insights and feedback on this
> > > > proposal.
> > > > >
> > > > >
> > > > >
> > > > > Subhag Oak  |  Senior Program Manager
> > > > >
> > > > > Visual Studio, Client Tools
> > > > >
> > > > > soak@microsoft.com
> > > > >
> > > > > 425 707 5598 office
> > > > >
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: agrieve@google.com [mailto:agrieve@google.com] On Behalf Of
> > > > > Andrew Grieve
> > > > > Sent: Wednesday, October 8, 2014 4:40 AM
> > > > > To: Shazron
> > > > > Cc: tommy-carlos williams; dev@cordova.apache.org
> > > > > Subject: Re: Build signed archives using CLI
> > > > >
> > > > >
> > > > >
> > > > > For Android Gradle, what's in (and experimental) right now:
> > > > >
> > > > >
> > > > >
> > > > > Environment variable "RELEASE_SIGNING_PROPERTIES_FILE" points to
a
> > > > > .properties file that contains:
> > > > >
> > > > >
> > > > >
> > > > > storeFile=relative/path/to/keystore.p12
> > > > >
> > > > > storePassword=SECRET1
> > > > >
> > > > > storeType=pkcs12
> > > > >
> > > > > keyAlias=DebugSigningKey
> > > > >
> > > > > keyPassword=SECRET2
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Topics to discuss:
> > > > >
> > > > >
> > > > >
> > > > > 1) Combine platform info into one file, or leave separate?
> > > > >
> > > > > - Leaning towards together
> > > > >
> > > > > 2) have config.xml point to signing info?
> > > > >
> > > > > - I think no, since signing info you often want to not check in /
> > keep
> > > > > secure
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Strawman:
> > > > >
> > > > > If a file "cordova-keys.json" exists as a sibling to www/, then use
> > > > > it. It should look like:
> > > > >
> > > > > {
> > > > >
> > > > >   "android": {
> > > > >
> > > > >     "storeFile": "relative/path.p12"
> > > > >
> > > > >      ...
> > > > >
> > > > >   },
> > > > >
> > > > >   "ios": {
> > > > >
> > > > >   },
> > > > >
> > > > >   ...
> > > > >
> > > > > }
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Android signs debug builds as well (not sure if other platforms do
> > > > > this too?), so maybe also allow
> > > > >
> > > > >   "android-release" as an alias for "android", and
> > > > >
> > > > >   "android-debug"
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Tue, Oct 7, 2014 at 6:52 PM, Shazron <shazron@gmail.com<mailto:
> > > > > shazron@gmail.com>> wrote:
> > > > >
> > > > >
> > > > >
> > > > > > I did open an issue for this two years ago:
> > > > >
> > > > > > https://issues.apache.org/jira/browse/CB-1369
> > > > >
> > > > > > and we did discuss this as well 2 yrs ago:
> > > > >
> > > > > > http://apache.markmail.org/thread/xxlmjjzgnctvsqnm
> > > > >
> > > > > >
> > > > >
> > > > > > Seems to be of great value - so let's get going on this ;) The
> CLI
> > > > > > has
> > > > >
> > > > > > (I think) matured more since then to allow this
> > > > >
> > > > > >
> > > > >
> > > > > >
> > > > >
> > > > > > On Tue, Oct 7, 2014 at 3:44 PM, tommy-carlos williams
> > > > >
> > > > > > <tommy@devgeeks.org<mailto:tommy@devgeeks.org>>
> > > > >
> > > > > > wrote:
> > > > >
> > > > > >
> > > > >
> > > > > > > Frederico’s workflow is the same as ours. I would love
to see
> > > > >
> > > > > > > something happen To improve this, the less time I spend
in
> Xcode,
> > > > >
> > > > > > > the happier I am
> > > > >
> > > > > > ;)
> > > > >
> > > > > > >
> > > > >
> > > > > > >
> > > > >
> > > > > > >
> > > > >
> > > > > > > On 7 October 2014 at 8:48:40, Frederico Galvão (
> > > > >
> > > > > > > frederico.galvao@pontoget.com.br<mailto:
> > > > > frederico.galvao@pontoget.com.br>) wrote:
> > > > >
> > > > > > >
> > > > >
> > > > > > > I can already get the ultimate .apk through "cordova build
> > android
> > > > >
> > > > > > > --release", but I already have the required .properties
> properly
> > > > >
> > > > > > configured
> > > > >
> > > > > > > in my platform/android folder, specifying the path and
name to
> my
> > > > >
> > > > > > > keystores. The "cordova build android --release" already
gives
> me
> > > > >
> > > > > > > the signed and ready .apk, all I have to do is upload it
to
> > > > > play.google.com.
> > > > >
> > > > > > >
> > > > >
> > > > > > > I have never, however, used cordova's CLI to build the
final
> > > > >
> > > > > > > artifact for iOS (IPA) for iTunes. All I do is run "cordova
> > > > >
> > > > > > > prepare", and use xCode
> > > > >
> > > > > > from
> > > > >
> > > > > > > then on to build, package, sign, and upload.
> > > > >
> > > > > > >
> > > > >
> > > > > > > 2014-10-06 16:52 GMT-03:00 Parashuram Narasimhan (MS OPEN
> TECH) <
> > > > >
> > > > > > > panarasi@microsoft.com<mailto:panarasi@microsoft.com>>:
> > > > >
> > > > > > >
> > > > >
> > > > > > > > How about a "cordova package" command, that would
be for
> > > > > > > > packaging
> > > > >
> > > > > > > > the
> > > > >
> > > > > > > app
> > > > >
> > > > > > > > for the store? Note that different platforms may have
> different
> > > > >
> > > > > > > > requirements for certs, signing etc. So it may make
sense to
> > > > >
> > > > > > > > promote
> > > > >
> > > > > > this
> > > > >
> > > > > > > > to a different command and let each command take care
of
> > > > > > > > packaging
> > > > >
> > > > > > > > the
> > > > >
> > > > > > > app
> > > > >
> > > > > > > > for the store. This command will also mean that developers
> > don’t
> > > > >
> > > > > > > > have
> > > > >
> > > > > > to
> > > > >
> > > > > > > go
> > > > >
> > > > > > > > over to the native projects when they finally want
to publish
> > > > >
> > > > > > > > their
> > > > >
> > > > > > apps
> > > > >
> > > > > > > to
> > > > >
> > > > > > > > the store.
> > > > >
> > > > > > > >
> > > > >
> > > > > > > > -----Original Message-----
> > > > >
> > > > > > > > From: Josh Soref [mailto:jsoref@blackberry.com]
> > > > >
> > > > > > > > Sent: Monday, October 6, 2014 12:46 PM
> > > > >
> > > > > > > > To: dev
> > > > >
> > > > > > > > Subject: Re: Build signed archives using CLI
> > > > >
> > > > > > > >
> > > > >
> > > > > > > > if you do:
> > > > >
> > > > > > > > Cordova build --release,
> > > > >
> > > > > > > > The blackberry10 platform will generate a signed image...
> > > > >
> > > > > > > >
> > > > >
> > > > > > > > On 10/6/14, 3:18 PM, "Andrew Grieve" <agrieve@chromium.org
> > > <mailto:
> > > > > agrieve@chromium.org>> wrote:
> > > > >
> > > > > > > >
> > > > >
> > > > > > > > >AFAIK, I don't think there's any technical roadblocks.
Just
> > > > > > > > >need
> > > > >
> > > > > > > > >a proposal for how it should look, and then a
patch & docs
> to
> > > > > > > > >add
> > > > > it!
> > > > >
> > > > > > > > >
> > > > >
> > > > > > > > >For Android's hot-off-the-press gradle support,
you can set
> an
> > > > >
> > > > > > > > >environment variable that points to a .properties
file for
> > > > >
> > > > > > > > >signing builds. This shows one way to go about
it, but I'm
> not
> > > > > > > > >in
> > > > >
> > > > > > > > >love with
> > > > >
> > > > > > the
> > > > >
> > > > > > > > .properties idea.
> > > > >
> > > > > > > > >
> > > > >
> > > > > > > > >On Mon, Oct 6, 2014 at 2:48 PM, Victor Sosa
> > > > >
> > > > > > > > ><sosah.victor@gmail.com<mailto:sosah.victor@gmail.com>>
> > > > >
> > > > > > > > >wrote:
> > > > >
> > > > > > > > >
> > > > >
> > > > > > > > >> Hi community.
> > > > >
> > > > > > > > >>
> > > > >
> > > > > > > > >> Been looking at this topic and wondering
why the build
> > > > > > > > >> command
> > > > >
> > > > > > > > >>does not create signed archives. Digging a
little bit
> found a
> > > > >
> > > > > > > > >>lot of differences in the platforms to create
these
> archives.
> > > > >
> > > > > > > > >>
> > > > >
> > > > > > > > >> For instance, in Android you need to 1. Export
your APK in
> > > > >
> > > > > > > > >> release mode (--release flag) 2. Sign your
APK (you
> already
> > > > >
> > > > > > > > >> need a RSA key)
> > > > >
> > > > > > > > >>
> > > > >
> > > > > > > > >> In iOS, you need to:
> > > > >
> > > > > > > > >> 1. Export your APP using --device flag (--release
seems to
> > > > >
> > > > > > > > >> export
> > > > >
> > > > > > for
> > > > >
> > > > > > > > >>emulator only) 2. Either use XCode (UI-based)
and sign the
> > > > >
> > > > > > > > >>archive or use xcrun (headless
> > > > >
> > > > > > > > >> process)
> > > > >
> > > > > > > > >>
> > > > >
> > > > > > > > >> Besides these differences, what is preventing
Cordova from
> > > > >
> > > > > > > > >> providing a generic one-way to build these
signed,
> > > > > ready-to-publish archives?
> > > > >
> > > > > > > > >>
> > > > >
> > > > > > > > >> Perhaps I'm missing something here...? I
really appreciate
> > > > > > > > >> your
> > > > >
> > > > > > > > >>insights on this topic
> > > > >
> > > > > > > > >>
> > > > >
> > > > > > > > >> Thanks!
> > > > >
> > > > > > > > >>
> > > > >
> > > > > > > > >> --
> > > > >
> > > > > > > > >> Victor Adrian Sosa Herrera
> > > > >
> > > > > > > > >> IBM Software Engineer
> > > > >
> > > > > > > > >> Guadalajara, Jalisco
> > > > >
> > > > > > > > >>
> > > > >
> > > > > > > >
> > > > >
> > > > > > > >
> > > > >
> > > > > > > >
> > ----------------------------------------------------------------
> > > > > > > > --
> > > > >
> > > > > > > > --- To unsubscribe, e-mail:
> dev-unsubscribe@cordova.apache.org
> > > > > <mailto:dev-unsubscribe@cordova.apache.org>
> > > > >
> > > > > > > > For additional commands, e-mail: dev-help@cordova.apache.org
> > > > <mailto:
> > > > > dev-help@cordova.apache.org>
> > > > >
> > > > > > > >
> > > > >
> > > > > > >
> > > > >
> > > > > > >
> > > > >
> > > > > > >
> > > > >
> > > > > > > --
> > > > >
> > > > > > >
> > > > >
> > > > > > > *Frederico Galvão*
> > > > >
> > > > > > >
> > > > >
> > > > > > > Diretor de Tecnologia
> > > > >
> > > > > > >
> > > > >
> > > > > > > PontoGet Inovação Web
> > > > >
> > > > > > >
> > > > >
> > > > > > >
> > > > >
> > > > > > > ( +55(62) 8131-5720
> > > > >
> > > > > > >
> > > > >
> > > > > > > * www.pontoget.com.br<http://www.pontoget.com.br>
<
> > > > > http://www.pontoget.com/>
> > > > >
> > > > > > >
> > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > *Frederico Galvão*
> > > >
> > > > Diretor de Tecnologia
> > > >
> > > > PontoGet Inovação Web
> > > >
> > > >
> > > > ( +55(62) 8131-5720
> > > >
> > > > * www.pontoget.com.br <http://www.pontoget.com/>
> > > >
> > >
> >
>



-- 

*Frederico Galvão*

Diretor de Tecnologia

PontoGet Inovação Web


( +55(62) 8131-5720

* www.pontoget.com.br <http://www.pontoget.com/>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message