Code-signing: Sign the app or explain to the user how to open an unsigned app

[schoeps]

We need to explain the user on the download page that one has to go to preferences -> security -> general -> ... to open the unsigned app for the first time. Or shall we get an Apple certificate?

---

Andrew's notes:

References

• Thoughts on code-signing from wjk #196
• "Signing and Notarisation of dmg losing signature info of bundled libraries" on Apple Developer Forum

[apjanke]

Let's get an Apple certificate! That will be a much better user experience.

I already have an Apple Developer account as appledev@apjanke.net. If you don't mind the binaries being signed by an Individual/Sole Proprietor account, I can just use that. That might be good enough for our first release. Getting an "octave-app.org" organizational Apple certificate might take some official incorporation and paperwork, which I don't know if we want to get in to just yet.

[schoeps]

Agreed!

[jlllopis]

+1

[apjanke]

I've added code signing support, but I'm not sure if it's working. Could you try downloading and installing beta4 - https://github.com/octave-app/octave-app/releases/tag/v4.4.0-beta4 - and tell me what happens?

[schoeps]

I see a dialog that complains that the app is neither from the app store nor from a verified developer.

[apjanke]

Darn it. I guess I need to do something else to configure it right. Looking in to it.

[apjanke]

Ah, here's a hint:

$ spctl -vvv -a -t open --context context:primary-signature /Applications/Octave-4.4.0.app
/Applications/Octave-4.4.0.app: rejected (invalid destination for symbolic link in bundle)
origin=Developer ID Application: Andrew Janke (R7H2BFWJAB)

Looks like we may have to prune some symlinks in the app. The symlinks into the internal Homebrew installation are invalid. And it may not link the symlink to system /var, either.

[apjanke]

Well, I tried cleaning up all the dead symlinks from Homebrew itself, and removing the var/ symlink, and I'm still getting the same error. Maybe code signing doesn't like relative symlinks in the style that Homebrew uses, because that's all I see left when I do a find /Applications/Octave-4.4.0.app -type l. In which case we are probably SOL on this.

[schoeps]

I did some reading and I did not find any document that supports the fact that symlinks are forbidden in app bundles (rather the opposite). However, maybe it's due to their relative nature? To test this, we could either convert all relative links to absolute ones after the creation of the bundle (something like ln -sf "$(greadlink -f $symlink)" "$symlink") or even try to patch homebrew to create absolute links from the beginning. What do you think?

[apjanke]

That's an idea. I'll give it a shot.

[schoeps]

Any progress? You could also try to replace linked files by copies cp $(readlink link) link.... not very clever and producing a huge bundle but may help to debug the signing....?! I'd day this is the last missing piece for a 4.4.0 release.

[apjanke]

Well. I tried:

• that approach of replacing all the symlinks with absolute-path symlinks
• removing the var/ -> /usr/local/var symlink
• signing the app while it's in its final /Applications/Octave-4.4.0.app location

both alone and in conjunction, and it's still not working. I'm still getting an error about invalid symlink destinations when I try to validate it.

$ spctl -vvvv -a -t open --context context:primary-signature /Applications/Octave-4.4.0.app
/Applications/Octave-4.4.0.app: rejected (invalid destination for symbolic link in bundle)
origin=Developer ID Application: Andrew Janke (R7H2BFWJAB)

Googling around for this error isn't being very useful, either. Like you say, there's no docs that say symlinks are forbidden.

I also tried that last-ditch approach of replacing links with file copies by doing cp -R $(readlink $link) $link. That expanded the app bundle to 7 GB, so it won't be useful for actually distributing the app. But it did get the code signing to work; validation passes:

$ spctl -vvvv -a -t open --context context:primary-signature /Applications/Octave-4.4.0.app
/Applications/Octave-4.4.0.app: accepted
source=Developer ID
origin=Developer ID Application: Andrew Janke (R7H2BFWJAB)

So I think we can safely say that the problem really is related to symlinks.

I don't know what else to try at this point. So as a next step, I'm going to try contacting Apple Developer Support and see if they can help with this issue.

[apjanke]

I've also confirmed that having the bundled var/ link to /usr/local/var on its own will trigger the "invalid destination for symbolic link" rejection, by trying just that in conjunction with copying all the symlinked files. So we probably won't be able to do that if we want to sign the app.

[apjanke]

There is a complication to signing: By default, "global" packages are installed to somewhere under $PREFIX, I think under $PREFIX/share/octave. This won't work with a signed app; it requires the contents of the app bundle to remain unchanged. So this will break global packages.

We need to find a way to redirect the location of global packages, and choose a good place for them. The pkg prefix command lets you redirect the user's installation location, but there's no direct equivalent for the global packages. There's a pkg global_list command that lets you redirect the global package list file; maybe that file contains a directive to indicate the prefix for global package installation.

[schoeps]

Sorry, I do not get it. The "global" packages are installed at compile time (in the case of Homebrew in /usr/local/opt/octave) and you do not touch them afterwards. So signing should be no issue? "Normal" packages go to some user folder (~/octave). Why is our app different than the classical Homebrew case?

[apjanke]

The "global" packages are installed at compile time (in the case of Homebrew in /usr/local/opt/octave) and you do not touch them afterwards.

Is that really the case? My understanding from reading http://octave.org/doc/interpreter/Installing-and-Removing-Packages.html#Installing-and-Removing-Packages is that if you pass the -global option to pkg install (or if you are root (not relevant here)), then global packages can be installed at any time.

I'm talking specifically about Octave packages installed by Octave's pkg command here, not packages in the general sense of the things installed by Homebrew formulae, or Octave itself.

Why is our app different than the classical Homebrew case?

I don't think it is different. Based on our emails with sshah, I think that Homebrew Octave users have probably been seeing crashes for the same reason when they upgrade from one Octave version to another and try to use the control package installed with the old version. I bet we just haven't been hearing about it because a simple reinstallation of the control package fixes it, and running multiple Octaves side-by-side is an unusual case.

I can reproduce the same crash by just installing the Homebrew formulae octave and octave-octave-app side-by-side on my computer, doing pkg install -forge control in one of them, and trying to run it in the other. A control package installed by one of them will cause the other one to crash.

[apjanke]

Apple developer forum post about this issue: https://forums.developer.apple.com/message/322873

[schoeps]

I cannot access the website (normal Apple ID, no dev account) but I guess you will inform us if you discover anything, right? :)

[apjanke]

Yep.

I think you should be able to get on the forums with read-only access with a regular Apple ID (no paid developer account), too. Try logging in with your normal Apple ID and creating a forum account when it prompts you.

[apjanke]

Changing the milestone on this from 4.4.0 to The Future, since it looks like I'm going to have to go through Apple Developer Support to make any further progress on this, and who knows how long that will take. Don't think we should block 4.4.0 or 4.4.1 for this reason.

[apjanke]

See also: #196