Feature request - create and sign package file

[jasonhinkle]

In my build script, after signing the .app I create a .pkg file and sign that. Because Application Loader requires the app to be packaged up for submission. You must have this file in order to submit the app to the app store.

Even though it is more than technically signing - it seems like it would be appropriate to include in electron-osx-sign because it is the final step for MAS preparation (and there is more signing involved).

Here is the code in my script that does this:

APP_PATH="MyApp.app"
RESULT_PATH="MyApp.pkg"
APP_KEY="3rd Party Mac Developer Application: Company, Inc (C123K93QGT)"
INSTALLER_KEY="3rd Party Mac Developer Installer: Company, Inc (C123K93QGT)"

# build the pkg installer file which application loader expects
productbuild --component "$APP_PATH" /Applications --sign "$INSTALLER_KEY" "$RESULT_PATH"

# sign the package file (seems redundant, but otherwise binary is rejected by itunesconnect)
codesign -fs "$APP_KEY" "$RESULT_PATH"

[sethlu]

@jasonhinkle I'm thinking about adding a second bin in package.json named electron-osx-build or else that may have some same features like what are included in electron-osx-sign to detect mas or darwin for certificate matching. Then with electron-osx-sign installed, the command to build .pkg could be accessible in CLI. With require('electron-osx-sign') directed to the signing function, another function could be mapped to require('electron-osx-sign).build() as the API for automation of productbuild. The reason I'm thinking in this way's that for distributing apps outside the MAS, it's not really necessary (at most times) to package them. People may want to save them in dmgs/zips.
What do you think about this?

[sethlu]

This feature may under be under some similar situation as mentioned in electron/packager#33.

[jasonhinkle]

I can see a reason to split them because the osx-sign should be responsible for signing. But there is that pkg file that needs to be created and it seems a little weird that osx-sign would be responsible for that, which would make a case for osx-build.

The only weird thing is that the creation of the pkg file also has a signing parameter. So, in a way creating the pkg does also include signing. And then the pkg file has to be additionally signed again as the last step.

There is also electron-build module that already creates .dmg files to make osx distribution files, though I don't think it creates .pkg or does anything as far as the mac app store.

[sethlu]

I've just updated a branch which supports productbuild with electron-osx-flat, and guess this should act as a quick way to pack for shipping:
https://github.com/sethlu/electron-osx-sign/tree/electron-osx-flat

[jasonhinkle]

Nice. So the usage is you run electron-osx-sign first to sign the .app, then run electron-osx-flat to create the signed .pkg file?

[sethlu]

@jasonhinkle yep. That's what I thought may work, with which the electron-osx-sign still functions as a signing tool, while electron-osx-flat as a packing helper. So two steps of preparing for app store distribution would be:

electron-osx-sign my_app.app # to first sign
electron-osx-flat my_app.app # then to create pkg

[jasonhinkle]

Awesome, I'll try to implement this into my build process and see how it goes. Thanks!

[sethlu]

@jasonhinkle No worries. Try adding the --verbose flag for logging if anything wrong occurs. I'm sure it should only rarely happen.

[jasonhinkle]

Ok so I went through the entire process and everything worked with producing a .pkg file, however the final signing of the pkg didn't occcur. I don't really understand why this is necessary because productbuild does have the --sign argument. However in my experience if the .pkg is then not signed again afterwards (with the developer key - not the installer key), it gets rejected once it is uploaded to itunesconnect. The error in itunesconnect will say "code object is not signed at all".

For my own app, as a final step I run this and my package has passed validation in itunesconnect:

codesign -fs "3rd Party Mac Developer Application: MyCompany, Inc (C296K93QYG)" "My App-mas-x64/My App.pkg"

Here's my command line output:

Jasons-MBP:Tube-DL jason$ electron-osx-flat "My App-mas-x64/My App.app" --verbose
No `--pkg` passed in arguments, will fallback to default, inferred from the given application.
No `--install` passed in arguments, will fallback to default `/Applications`.
No `--identity` passed in arguments, matching identities...
No `--platform` passed in arguments, cheking Electron platform...
Flattening application...
> application        My App-mas-x64/My App.app
> package-output     My App-mas-x64/My App.pkg
> install-path       /Applications
> identity           3rd Party Mac Developer Installer: MyCompany, Inc (B796K93QHT)
Flattening with productbuild...
Application flattened: My App-mas-x64/My App.pkg
Jasons-MBP:Tube-DL jason$ 

Then verifying the pkg is signed, though:

Jasons-MBP:My App-mas-x64 jason$ codesign -dvvv My\ App.pkg
My App.pkg: code object is not signed at all

[jasonhinkle]

Here's exactly the commands that I ran by the way:

npm install https://github.com/sethlu/electron-osx-sign/tarball/electron-osx-flat -g
npm install https://github.com/sethlu/electron-packager/tarball/master -g
electron-packager . "My App" --app-bundle-id=com.mycompany.myapp --helper-bundle-id=com.mycompany.myapp.helper --app-version=2.0.1 --build-version=2.0.102 --platform=mas --arch=x64 --version=0.36.7 --ignore="node_modules/electron-*|assets/bin/win" --icon=./assets/images/Icon.icns --overwrite
electron-osx-sign "My App-mas-x64/My App.app" --verbose
electron-osx-flat "My App-mas-x64/My App.app" --verbose

[sethlu]

@jasonhinkle The code seems right. However, I'm not sure if the .pkg flat file needs code-signed, as previously some binaries are excluded from the signing process, which fact had the .pkg rejected from iTunes Connect.
There haven't been so much of this case that I found on any forums: https://discussions.apple.com/message/18533567#18533567. Yet I think as long as productbuild doesn't complain, the package .pkg should be fine for shipping (but not taking the missing binaries from signing into account).
I'll look further into this... My app in iTunes Connect's now in review: The .pkg file was not code-signed at the time of uploading. So I have the same output as yours:

$ codesign --verify --verbose Doodle-mas-x64.pkg 
Doodle-mas-x64.pkg: code object is not signed at all

When iTC gets back to me I could know more details about the signed .pkg package.
In addition: As the installer packages are what actually install the binaries. I'm thinking if to nevertheless sign them, we may have to use the installer cert, instead of the app cert. However, I'm not certain about this.

[sethlu]

Few notes from Mac Developer Library:
https://developer.apple.com/library/mac/documentation/IDEs/Conceptual/AppDistributionGuide/DistributingApplicationsOutside/DistributingApplicationsOutside.html
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man8/spctl.8.html#//apple_ref/doc/man/8/spctl
I find spctl should fit what we intended codesign to do in this case, but not for mas builds.

[jasonhinkle]

I'll give it more testing after my current app is approved or declined (it's currently "in review"). Perhaps I signed it unnecessarily a 2nd time (which I thought was odd at the time anyway, but I was getting "not signed at all" errors.

If my app status isn't updated soon, perhaps I'll create a dummy app just to test submitting binaries.

[sethlu]

@jasonhinkle My project's also currently in review. We'll see how the apps/pkgs go with the iTC checking. For the additional binary signing, I'll think about an easy solution to testing.

[jasonhinkle]

UPDATE: disregard this, I think it was coming from ffmpeg which is packaged in my app. Looks like I might have to do a custom build to get rid of that.

---

My app got rejected with this reason "The use of non-public APIs can lead to a poor user experience should these APIs change in the future, and is therefore not permitted. The app includes SecIdentityCreate from the framework '/System/Library/Frameworks/Security.framework/Versions/A/Security'."

Wonder what that's about? Did you get anything similar? As far as I know my app doesn't have anything that references the Security framework.

[sethlu]

@jasonhinkle I'm still waiting for approval... But here's what I found online for you:
http://ffmpeg.org/doxygen/trunk/tls__securetransport_8c_source.html
It seems that ffmpeg does call the SecIdentityCreate on line 41.

[jasonhinkle]

Thanks for checking that out - funny that they bothered to comment above the line! I've been trying unsuccessfully to do a custom build today, it's a bit of a pain.

So it looks like my app won't ever be accepted into the store because it downloads videos from YouTube but I have a couple more that use ffmpeg but I believe are fully MAS compatible. If you're curious, the app I've been working on all this time is at https://github.com/jasonhinkle/Tube-DL. It's a simple app, but I'd like to think it's somewhat interesting for Electron just because of the use of external binaries.

[sethlu]

@jasonhinkle I'm not sure, but I may help to see if there'll be alternatives that do not call SecIdentityCreate on OS X. There should be some ways to get some of the rest apps onto MAS.
I'll have a check on your Tube-DL. Seems like that I don't have to go somewhere else for this neat solution. 😉