Xpra: Ticket #1340: OSX PKG signing

Follow up form #641. (see also #840)

Links:

Once the certificate have magically appeared in Xcode and the keychain (..), we can sign the Xpra.app bundle, the PKG and DMG files:

codesign --deep --force --verify --verbose --sign "Developer ID Application: Antoine Martin (XXXXXXXXXX)" Xpra.app
codesign --deep --force --verify --verbose --sign "Developer ID Application: Antoine Martin (XXXXXXXXXX)" Xpra.dmg
productsign --sign "Developer ID Installer: Antoine Martin (XXXXXXXXXX)" Xpra.pkg Xpra-signed.pkg

The signature can be verified with:

codesign --verify --verbose=2 Xpra.app
spctl --assess --verbose=4 --type=execute Xpra.app
spctl --assess --verbose=4 --type=execute Xpra.dmg
spctl --assess --verbose=4 --type=install Xpra-signed.pkg

But this fails for signing "Xpra.app" if I keep the Xpra_NoDock.app nested inside the Xpra.app, it complains:

image/Xpra.app: invalid Info.plist (plist or signature have been modified)
In subcomponent: /Users/osx/Xpra-svn/trunk/osx/image/Xpra.app/Contents/Xpra_NoDock.app

Removing the nested app fixes this, but there must be something I can change in the Info.plist (or elsewhere?) to be able to bundle it.

@smo: what am I missing?



Thu, 13 Oct 2016 16:48:55 GMT - Antoine Martin: owner, description changed

(edit: added verify for PKG - full error message)


Thu, 13 Oct 2016 17:17:06 GMT - Antoine Martin:

App store submission steps:


Fri, 14 Oct 2016 05:05:05 GMT - Antoine Martin: owner, status changed

Despite the hopelessly unhelpful and misleading error message from the codesign tool (..), I've narrowed it down through trial and error (mostly error):

Bringing the Info.plist closer to the main one "fixes" things, done in r14152.

Along the way I found that changing CFBundleExecutable is not possible in the subapp!? It's fortunate that we don't use this executable directly.

Now onto app submission. Let's hope it is as much fun as this, not.


Fri, 14 Oct 2016 12:32:50 GMT - Antoine Martin:

r14154 + r14155 adds hooks to do the signing as part of the app / dmg / pkg scripts.

So until I move to a newer build host, the process is:

(see User interaction is not allowed: trying to sign an OSX app using codesign)


Appstore fun:


Sat, 15 Oct 2016 07:03:00 GMT - Antoine Martin:

More fixes:

What remains:


See also:


Sat, 15 Oct 2016 08:41:52 GMT - Antoine Martin:

Alternatively using productbuild:

productbuild --component ./image/Xpra.app \
    /Applications \
    ./image/Xpra-1.0.pkg  \
    --sign "3rd Party Mac Developer Installer"

The resulting installer package lacks any icons or text but seems to install OK. Only one error remains for "Application Loader" upload for this one: ITMS-90259: Bad Bundle Executable...

Or even:

pkgbuild --analyze --root ./image/Xpra.app ./image/XpraComponents.plist
#edit XpraComponents.plist and set {{{BundleIsRelocatable}}} to false
pkgbuild --root ./image/Xpra.app \
    --component-plist ./image/XpraComponents.plist \
    --install-location "/Applications" \
    ./Xpra.pkg
#generate the Distribution.xml file:
productBuild --synthesize --package ./Xpra.pkg ./Distribution.xml
# modify it using the same data as found in our make-PKG.sh script, and:
# change "#base.pkg" to "#Xpra.pkg"
# add the product id and version line
productbuild --distribution ./Distribution.xml --package-path . \
    --sign "3rd Party Mac Developer Installer" \
    ./Xpra-Installer.pkg

Same "bad bundle executable" error, and also missing the 512x512 icons...


More links:


Sat, 15 Oct 2016 20:06:34 GMT - Antoine Martin:

I can get a little bit further by:

The entitlements file was added in r14166. (it's not clear if the same entitlements should be used for all the files: I doubt the system is capable of isolating the code running in libraries from its entrypoint)


Then you need to make an upload to itunes... which takes a lot of time and effort. And then you get some more errors via email! (this is some kind of bad joke) Invalid Signature: (..) satisfies its Designated Requirement test-requirement: code failed to satisfy specified code requirement(s) - could they have worded it more ambiguously perhaps? Before I started signing the "so" / "dylib" / etc, the error was different for those: code object is not signed at all In architecture: i386). Rinse and repeat until you find the right combination. But you can't delete versions on there, so you have to bump the CFBundleVersion every time. How convenient.


More links:


Sun, 16 Oct 2016 15:05:09 GMT - Antoine Martin: attachment set

to make the package non relocatable


Sun, 16 Oct 2016 16:23:19 GMT - Antoine Martin: attachment set

work in progress to generate a PKG compatible with the appstore


Sun, 16 Oct 2016 16:25:28 GMT - Antoine Martin:

A big part of the difficulty is that it's non-trivial to embed shell scripts... Because shiny. Or something. (and also because it takes way too long to test anything)

With the patch attached, the codesign step shows:

(..)
image/Xpra.app/Contents/Helpers/Bug_Report: replacing existing signature
image/Xpra.app/Contents/Helpers/Bug_Report: signed generic [Bug_Report]
(..)

Note that is uses "generic" and not "signed Mach-O thin (i386)" like it does for all the binaries. And then much much later (..), you get an email (..) saying the build cannot be uploaded:

org.xpra.Xpra.pkg/Payload/Xpra.app: code object is not signed at all
In subcomponent: org.xpra.Xpra.pkg/Payload/Xpra.app/Contents/Helpers/Bug_Report

See:

Maybe we can change the wrappers so that the "MacOS" binary executes the real "Python" executable (renamed if needed) with the script as argument instead. (and move the scripts somewhere else..)

Still TODO:

etc.


Mon, 17 Oct 2016 10:05:48 GMT - Antoine Martin:

A gem in http://prod.lists.apple.com/archives/xcode-users/2013/Oct/msg00067.html: In addition to my entitlements file I needed to create an info.plist file and embed it into the binary by adding the following linker flag:

-sectcreate __TEXT __info_plist SandboxUnixCommand/SandboxUnixCommand-Info.plist

Well, obviously... ahem. Magic TEXT section values! More info here: Gimmedebugah: how to embedded a Info.plist into arbitrary binaries


Mon, 17 Oct 2016 11:33:04 GMT - Antoine Martin: attachment set

updated patch


Mon, 17 Oct 2016 13:22:55 GMT - Antoine Martin:

Lots more nasty tricks to beat this mess into shape:


Tue, 18 Oct 2016 15:19:29 GMT - Antoine Martin:

At last a package that both runs and uploads to the appstore:


Thu, 20 Oct 2016 05:14:47 GMT - Antoine Martin: attachment set

appstore view


Thu, 20 Oct 2016 05:15:22 GMT - Antoine Martin:

as shown on the https://itunesconnect.apple.com/ appstore control page: appstore view


Thu, 20 Oct 2016 11:54:33 GMT - Antoine Martin:

Sound sub-app fixes:


Sun, 23 Oct 2016 06:53:25 GMT - Antoine Martin:

Some path fixes and updates:

Ideally, we would store our preferences in /Library/Preferences, but:

Then, we could handle Migrating an App to a Sandbox and have the preferences moved for us to the user sandbox.


Fri, 28 Oct 2016 10:02:26 GMT - Antoine Martin: milestone changed

I don't think this is going to happen anytime soon. Re-scheduling.

Their complaints after reviewing the app:


Sat, 19 Nov 2016 06:25:55 GMT - Antoine Martin: summary, milestone changed

Moving the appstore packaging to a new ticket: #1366

This purpose of this ticket is now only about signing the PKG. At least some of the latest PKG builds should be signed... I should make it easier to know which PKG are signed and which ones are not. (requires using a newer VM to sign.. which won't boot right now on my systems.. even with the Intel one..)

I'm not entirely sure what the actual difference is for users when installing signed vs unsigned packages. I've paid the fee for the privilege of having Apple sign the key. Does this make it easier to install the PKG on OSX versions with the more stringent security settings?


Mon, 21 Nov 2016 16:35:20 GMT - Antoine Martin: owner, status changed

Success. I have fixed my signing 10.10.x VM (it needs vbox 5.0 to boot, fails with 5.1 - fixes for running 5.0 on Fedora 25: Runtime/r0drv/linux: 4.8 mod_timer_pinned fix).

Uploaded both DMG and PKG r14467 builds signed with my developer key. @afarr: do these signed builds help with installation on newer versions of macosx? (you may need to turn the "stricter installation checks" setting back on again)


Fri, 02 Dec 2016 23:35:52 GMT - alas: owner changed

Odd.

I have an r14467 .dmg installed in my usual odd place - deleting and re-installing into the more usual /Applications directory works as usual, and likewise with the r14492 .dmg.

Double clicking on them, however, they fail the "Verifying 'Xpra'" validation test, "because it is from an unidentified developer".

I can't find any sign of the r14467 pkg though, or .dmg, in either the /dists or the /beta directories (so, where did I get the r14467 .dmg I already have?).

Trying to install the r14492 .pkg I get the usual security/unsigned (unknown developer) issue, but I'm not sure you signed that one.

I think you'll need to post another signed .pkg or even .dmg for me to check.


Tue, 06 Dec 2016 16:34:57 GMT - Antoine Martin: owner changed

1.0 should be signed, just released today. (the other ones disappeared because I needed to free some diskspace)


Note to self since this is not obvious, this is how we make the signed DMG / PKG:


Fri, 09 Dec 2016 01:46:40 GMT - alas: owner changed

Checking in xpra.org/beta/osx ... the 1.0 r14492 pkg (http://xpra.org/beta/osx/Xpra.pkg) both, once downloaded, trigger a security warning when trying to install (“Xpra.pkg” can’t be opened because it is from an unidentified developer.).

They indicate that they were posted/updated 11/27.

Handing this back to you... and chuckling that my username seems to have become 'alas' (I feel three breaths closer to Elizabethan-dom ... three breathless breaths, whatever that means).


Mon, 26 Dec 2016 09:46:56 GMT - Antoine Martin: owner changed

1.0 was released, meaning it is no longer in the beta area! Try here instead: http://xpra.org/dists/osx/x86/. (and the files in the beta area will soon disappear altogether to make way for 2.0 builds)

As for 'alas', that's your "name" in your account settings. The trac update now shows the name rather username. You should be able to change it yourself from your account profile - but it does have a nice ring to it, doesn't it?


Sat, 07 Jan 2017 11:26:43 GMT - Antoine Martin:

1.0.1 is also signed.


Mon, 09 Jan 2017 18:02:26 GMT - alas: attachment set

unknown developer error when installing .pkg


Mon, 09 Jan 2017 18:06:35 GMT - alas:

Err — alas... I seem to be triggering the same "unknown developer" error with the new 1.0.1 (Xpra-1.0.1-r14723.pkg) that I was mentioning getting with 1.0 in comment:20 (which I also repeated with Xpra-1.0-r14502).

I got the errors with the new 10.12.1 super-shiny mac OS, and then confirmed I'm also getting it with a 10.10.5 significantly-less-shiny mac.

Same message with 1.0 and 1.0.1, on 10.12.1 & 10.10.5.

unknown developer error when installing .pkg

Apple must have more hoops for you?


Mon, 09 Jan 2017 18:06:56 GMT - alas: owner changed


Sun, 12 Mar 2017 09:16:58 GMT - Antoine Martin: owner, milestone changed

Does it work any better with the beta 2.0 builds? Those are built and signed on the same system.


Fri, 30 Jun 2017 17:47:44 GMT - J. Max Mena: owner changed

Sadly, the latest 2.1 betas are still complaining about unidentified developers.


Fri, 30 Jun 2017 17:48:29 GMT - J. Max Mena: attachment set


Fri, 30 Jun 2017 18:19:05 GMT - Antoine Martin: owner changed

The certificate expired a few months back so I stopped signing the builds, you may want to try a build made around the time of comment:25 instead. (2.0.x)


Fri, 30 Jun 2017 18:19:34 GMT - Antoine Martin: owner changed


Fri, 14 Jul 2017 20:55:06 GMT - J. Max Mena: status changed; resolution set

Retried with a build from mid March, and still got the error, and that was the oldest 2.0 build available in the betas folder (dists had nothing relevant unless I missed something that obvious..which is possible).

Either way, based on the conversations we've had, I'm going to close this - if we want to revisit OSX signing, we can re-open this, but in the meantime, closing.

(As an aside, I think we need a "crickets" resolved option, but that's just me)


Thu, 20 Aug 2020 04:29:08 GMT - Antoine Martin:

See also #2015, #2441.


Sat, 23 Jan 2021 05:21:34 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1340