Return-Path: X-Original-To: apmail-cordova-dev-archive@www.apache.org Delivered-To: apmail-cordova-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 966E41784B for ; Thu, 9 Oct 2014 18:26:21 +0000 (UTC) Received: (qmail 64298 invoked by uid 500); 9 Oct 2014 18:26:21 -0000 Delivered-To: apmail-cordova-dev-archive@cordova.apache.org Received: (qmail 64259 invoked by uid 500); 9 Oct 2014 18:26:21 -0000 Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cordova.apache.org Delivered-To: mailing list dev@cordova.apache.org Received: (qmail 64241 invoked by uid 99); 9 Oct 2014 18:26:20 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Oct 2014 18:26:20 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of agrieve@google.com designates 209.85.218.49 as permitted sender) Received: from [209.85.218.49] (HELO mail-oi0-f49.google.com) (209.85.218.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Oct 2014 18:25:53 +0000 Received: by mail-oi0-f49.google.com with SMTP id a3so3934380oib.36 for ; Thu, 09 Oct 2014 11:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=JQIaa9b7in1UK9PGSfcb84uVmQDnHPdetxvuYIxvjCM=; b=HpFHKBucysrlvnk5wYk3BnODOULaTia2PDvCrnk8yTRtobzvvNprVS1eW+Fe0XH2Y9 Y5DIB/zo0HaKWEkmv5ezwEPnAUxVqG94Sgjl5QGwoLyVjxqDQVXfx2oYY1BVmVaakzXW N/p+m8KTPfEYXIaR/7I0zQNbPoweIxICDWymu9BqJ2w8AYSIH7n0/E6Y+dwb+hTaEx+a v3xSiFr73ywCPagmdDkh+gZa6oQHaIP5FEwLZL6A563bwWH6GO91viaxk1bfzFY6cKH2 lK89HLJMyp69DAXYNzUeouoYoYuzxC/62X8t0jJ3fE1uwJ6fd+AZ14kw77i9NoV/1FGK lXlQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=JQIaa9b7in1UK9PGSfcb84uVmQDnHPdetxvuYIxvjCM=; b=XZTp9NF5sd/99zplrAfPH5Wr+t4afRsm1eSKuJbJ+Vj7odPcHF0i3F14hZb9OHTbZU 09KNpRp4ajG1Dzx9M/sOJRHZUcqk/6wmMfbVPKvEdDifrpIaTs564nccJ2k/c0Fx2Mpa KtlgJSXsFZIjBf6JJWinSeN9brAyLOo6utTQY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:content-type; bh=JQIaa9b7in1UK9PGSfcb84uVmQDnHPdetxvuYIxvjCM=; b=VEnQ0R6O7JtAqHLnb5UkUoszQ1giy+iX6YUP3s/fPpnkAoEZyzbeg+TBSOzCe1dEI9 98llduCUvpYRTqvMLQQOGOWFMDaMUqvYs8pdgOS3XWrnDFI0+OUTtaHGBiav5/CL9y2t Ubbp36OMUvM42PvrgrSWQAVrjKF8WbOAajvkH0CT8Jk2MVO4Oh9NabI3KPBu6+9RGJuh Jru3CCtuL0/76Mpt87GJjGWG0mpyGZ0DyJR1MlhUYUM2ad4+PPBK74MtUFFqTZuTBoqg ZAnFenPwEX/ya0E2P3bu/r2c1RzlVQJRMxK19ZiNwKUzdrOux0mcHeIUxgCb8LjmgLH/ 56uw== X-Gm-Message-State: ALoCoQlojML/BeK4ZQmnM8UkZIr8LTrwfQQxGC/GvH7Hibds4KtqLAlSvDHoqZ2Onsh/Q8bAj9Cy X-Received: by 10.182.18.101 with SMTP id v5mr25410644obd.64.1412879151881; Thu, 09 Oct 2014 11:25:51 -0700 (PDT) MIME-Version: 1.0 Sender: agrieve@google.com Received: by 10.182.98.161 with HTTP; Thu, 9 Oct 2014 11:25:31 -0700 (PDT) In-Reply-To: References: <7a4401fb930347aa952b456b85e5fc97@DM2PR03MB366.namprd03.prod.outlook.com> <9379b384227a4ff2a474ec5cbfb79c76@BLUPR03MB065.namprd03.prod.outlook.com> From: Andrew Grieve Date: Thu, 9 Oct 2014 14:25:31 -0400 X-Google-Sender-Auth: pCvYy9sG_joVzO83EHx_Sn5nSRw Message-ID: Subject: Re: Build signed archives using CLI To: dev Content-Type: multipart/alternative; boundary=001a11c33060f581a20505018f6a X-Virus-Checked: Checked by ClamAV on apache.org --001a11c33060f581a20505018f6a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 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 ca= n, > meaning things like `cordova package ios` defaults to a code sign identit= y > 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 a= s > much as possible done through config.xml as Fredrico points out, and agre= e > 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 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 b= y > > the plugin and build infrastructure. This would allow you to place > > customized native assets that are unique to your project in a place tha= t > > you can check in and would be unaffected by an upgrade. > > > > Andrew's environment variable idea could also provide an alternate mean= s > > to specify platform specific values (what Soak mentions in the { }). > > > > -Chuck > > > > -----Original Message----- > > From: Frederico Galv=C3=A3o [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//. 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 : > > > > > 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 =E2=80=98packaging=E2=80=99 co= mmand for all > > > platforms, here is one > > > proposal: > > > > > > > > > > > > As we all know, packaging an application for deployment requires extr= a > > > steps that are specific to the native platforms. A new generic > > > Cordova CLI =E2=80=98package=E2=80=99 command can perform these platf= orm specific > > > actions to generate a final signed package ready for deployment: > > > > > > cordova package [platform] [--packageConfiguration] {-- > > > =E2=80=93-sign[location] > > > -- =E2=80=93-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 =E2=80=93packageConfiguration are interpreted by the r= espective > > > 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-signin= g > > > certificate, the provisioning profile or the code signing identity > > > (certificates along with public and private keys) respectively. > > > > > > > > > > > > e.g: > > > > > > =C2=B7 =E2=80=98cordova package iOS=E2=80=99 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 =3D iPhone Developer > > > > > > > > > > > > =C2=B7 =E2=80=98cordova package android=E2=80=99 would genera= te 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. > > > > > > > > > > > > =C2=B7 =E2=80=98Cordova package windows=E2=80=99 would genera= te a signed APPX > package. > > > This will use the following tools in the Windows SDK: > > > > > > =E2=80=A2 An unsigned packaged Windows Store app, = for > example, > > > an .APPX file created by using the app packager (MakeAppx.exe) tool > > > > > > =E2=80=A2 A valid code signing certificate, for ex= ample, a > > > Personal Information Exchange (.pfx) file created with the > > > MakeCert.exe and Pvk2Pfx.exe tools > > > > > > =E2=80=A2 SignTool, which is part of the Windows S= DK > > > > > > > > > > > > Here is how the package command should work. The proposal is to make > > > the =E2=80=98package=E2=80=99 command work on convention (similar to = the Cordova build > > > command) rather than config settings. The command would look out for > > > packaging assets in the =E2=80=9Cplatform\ [native-platform]=E2=80=9D= folder. > > > > > > > > > > > > For android, the contents of the ant.properties (keystore, password, > > > alias and alias password) would be used for packaging. If any of thes= e > > > 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 ar= e > > > 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 th= e > > > 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 =E2=80=9Cd:\cert\mycert.cer= =E2=80=9D --embed > > > =E2=80=9Cd:\cert\devprovision.mobileprovisioning=E2=80=9D > > > > > > 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=3Drelative/path/to/keystore.p12 > > > > > > storePassword=3DSECRET1 > > > > > > storeType=3Dpkcs12 > > > > > > keyAlias=3DDebugSigningKey > > > > > > keyPassword=3DSECRET2 > > > > > > > > > > > > > > > > > > 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 / kee= p > > > 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>> 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 > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > Frederico=E2=80=99s 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=C3=A3o ( > > > > > > > > frederico.galvao@pontoget.com.br > > frederico.galvao@pontoget.com.br>) wrote: > > > > > > > > > > > > > > > > I can already get the ultimate .apk through "cordova build androi= d > > > > > > > > --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>: > > > > > > > > > > > > > > > > > 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= =E2=80=99t > > > > > > > > > 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>> 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 > > > > > > > > > >> > > > > > > > > > >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 > > > > > > > > > > > > For additional commands, e-mail: dev-help@cordova.apache.org > > > > dev-help@cordova.apache.org> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > *Frederico Galv=C3=A3o* > > > > > > > > > > > > > > > > Diretor de Tecnologia > > > > > > > > > > > > > > > > PontoGet Inova=C3=A7=C3=A3o Web > > > > > > > > > > > > > > > > > > > > > > > > ( +55(62) 8131-5720 > > > > > > > > > > > > > > > > * www.pontoget.com.br < > > > http://www.pontoget.com/> > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > *Frederico Galv=C3=A3o* > > > > Diretor de Tecnologia > > > > PontoGet Inova=C3=A7=C3=A3o Web > > > > > > ( +55(62) 8131-5720 > > > > * www.pontoget.com.br > > > --001a11c33060f581a20505018f6a--