XojoFramework : code-signing problems and ISO

Targets macOS
1

I’m trying to figure out a way to deliver a properly code-signed OS X app built using Xojo 2014R2.1 or R3 using ISO format disk image.

Recent Xojo versions include XojoFramework which is a Bundle:
For background info, see this thread: https://forum.xojo.com/12162-symbolic-links-inside-xojo-framework

the top level of the bundle includes two symlinks:

$ls -lR XojoFrameWork.framework/
lrwxr-xr-x  1 me  503   26 Dec  4 08:57 Resources -> Versions/Current/Resources
drwxr-xr-x  4 me  503  136 Dec 10 09:35 Versions
lrwxr-xr-x  1 me  503   30 Dec  4 08:57 XojoFramework -> Versions/Current/XojoFramework

My app is properly code-signed (using the --deep option) and passes validation checks while on the hard disk, and while copied to a DMG format disk image.

However, when the DMG is converted to ISO9660/joliet, it appears that the symlinks break.

Oddly, this doesn’t stop the app from running: I can double-click it from the ISO and it runs just fine.

However, this appears to confuse gatekeeper, and it considers the signature invalid:

codesign -v /Volumes/TestSignature/MyApp.app
/Volumes/TestSignature/MyApp.app: code object is not signed at all
In subcomponent: /Volumes/TestSignature/MyApp.app/Contents/Frameworks/XojoFramework.framework

This is a problem for me, as I want to use ISO as a delivery mechanism (why? complex & esoteric reasons of cross-platform compatibility - let’s assume for this thread that I have to use ISO).

Given this problem, I’m wondering if

  • (A) I should probably “flatten” the XojoFramework.framework bundle to remove the symlinks?
  • (B) Does Xojo Inc consider this a problem, and would they consider making this change to their linker?
2

Storing a TARed version in the ISO isn’t acceptable?

3

In this case, sadly, no. If I could just use ZIP as a common file format, I would, but Windows doesn’t deal with zip files properly, so I’m investigating ISO as an alternative.

4

[quote=150923:@Michael Diehr]I’m trying to figure out a way to deliver a properly code-signed OS X app built using Xojo 2014R2.1 or R3 using ISO format disk image.

Recent Xojo versions include XojoFramework which is a Bundle:
For background info, see this thread: https://forum.xojo.com/12162-symbolic-links-inside-xojo-framework

the top level of the bundle includes two symlinks:

$ls -lR XojoFrameWork.framework/
lrwxr-xr-x  1 me  503   26 Dec  4 08:57 Resources -> Versions/Current/Resources
drwxr-xr-x  4 me  503  136 Dec 10 09:35 Versions
lrwxr-xr-x  1 me  503   30 Dec  4 08:57 XojoFramework -> Versions/Current/XojoFramework

My app is properly code-signed (using the --deep option) and passes validation checks while on the hard disk, and while copied to a DMG format disk image.

However, when the DMG is converted to ISO9660/joliet, it appears that the symlinks break.

Oddly, this doesn’t stop the app from running: I can double-click it from the ISO and it runs just fine.

However, this appears to confuse gatekeeper, and it considers the signature invalid:

codesign -v /Volumes/TestSignature/MyApp.app
/Volumes/TestSignature/MyApp.app: code object is not signed at all
In subcomponent: /Volumes/TestSignature/MyApp.app/Contents/Frameworks/XojoFramework.framework

This is a problem for me, as I want to use ISO as a delivery mechanism (why? complex & esoteric reasons of cross-platform compatibility - let’s assume for this thread that I have to use ISO).

Given this problem, I’m wondering if

  • (A) I should probably “flatten” the XojoFramework.framework bundle to remove the symlinks?
  • (B) Does Xojo Inc consider this a problem, and would they consider making this change to their linker?[/quote]

Joliet is a foreign format, so it drops some binary file attributes the Mac file system needs. What happens to your bundle is akin to copying it with the Windows file system. It breaks it just the same.

Zip your app before your place it in the ISO and it will be fine.

5

No.

No, this is just how OS X frameworks work.

6

Well, my point is that it used to work fine up until the more recent versions of Xojo in which XojoFramework was turned into a versioned Bundle. In fact, the app still runs just fine from ISO, it’s just apparently that GateKepper doesn’t like the fact that the symlinks are missing from the bundle.

7

Try the demo of AppWrapper 3 and see if it works. By pretty far the best you can buy to codesign your apps.

8

Joe, I believe I’ve asked you this before, but is there some compelling reason that Xojo switched the framework to a version’d bundle?

I totally understand “this is how Apple asks us to do it” - but, on the other hand, Xojo is a cross-platform authoring system, and I would argue that if there is a choice, it’s good to err on the side of making changes that are more cross-platform-compatible rather than less.

9

Unless AW3 flattens the XojoFramework, this wouldn’t help, but thanks for the suggestion.

10

One of the reasons is that we can include our own resources and localizations without conflicting with the user’s resources or making Apple think that your application is localized into languages that it actually isn’t.

11

More info: It looks like there are two issues interacting here.

  • ISO format disks can actually contain multiple filesystems (e.g. ISO9660, Joliet, UDF, HFS+ etc.) all on one disk. The kind of disk I’m making only includes ISO9660/Joliet. Although I believe ISO9660/Joliet is supposed to handle symlinks, it appears that the way I’m generating it (using hdiutil) doesn’t work. This could be an Apple bug, or perhaps just a ISO limitation.
  • I could probably generate a multiple-filesystem ISO (including HFS+) which I suspect would work fine, however, I’m trying to generate this filesystem on a Windows machine, and I’m pretty sure HFS+ ISOs can’t be made on Windows.
  • Whether an app is in good enough shape to run appears to be separate from whether an app is allowed to run: The app on ISO launches and runs just fine, but if you use apple’s tools spctl and codesign whether the app is "OK’, they give different answers.

To be clear: I do not fault Xojo for these issues, I’m just trying to figure out if there’s any way to work around them (other than going back to really old versions of Xojo)

12

Symlinks don’t survive in a non Mac file system. No golden fish survives without water :wink:

13

There was a tread not long ago about that. Don’t, or pack your app in a zip on Mac before moving it to Windows for packaging into the ISO. A Mac app bundle signing simply won’t survive if copied by a Windows system.

14

The irony here of course is that the whole point of versioned bundles was to allow flexibility, yet Apple now says “don’t use versioned bundles with code-signing”. And, the whole point of Apple stopping the use of Resource forks long ago was to make OS X more compatible with other filesystems. So, we’ve got a new fancy versioned bundle format (which will never actually have more than one version) and a code-signature facility which is supposed to protect users, but the end result is worse compatibility and loss of features. Sigh. (again, not blaming Xojo here, this is mostly on Apple).

15

Where are you code signing, are you code signing once the bundle is in the DMG or before you copy it to the DMG?

AFAIK, signing it first and then having the DMG break the symlinks, breaks the code signature. However if the symlinks are already broken then code signature should be fine.

Currently App Wrapper doesn’t flatten the framework bundle either and App Wrapper will not let you code sign apps on a disk that doesn’t support symlinks or ACLs.

App Wrapper has been tested with applications that have frameworks containing multiple versions. Although in all honesty, this situation shouldn’t happen!

Technically, it shouldn’t be too hard to remove the symlinks from the framework, several Xojo competitors do not create frameworks correctly, however there have been reports of failed code signing if the framework is malformed.

If you really must use a disk format that Apple doesn’t seem to link, have you thought about using an Apple Installer. So the user double clicks and the application is installed?

16

Edit: I’ve done some quick tests with removing the symlinks, and both spctl and codesign report it’s a mal-formed framework bundle. This happens even if i remove the symlinks first, then codesign the bundle.

17

Altering the bundle after code signing will break the code signature, so yeah do your destructiveness before.

18

You would think so, but I’ve done it both ways, and oddly, the result it the same : “bundle format unrecognized, invalid, or unsuitable” - it appears as if the signature validation doesn’t even happen.

None of this seems to affect whether the app can run : it runs just fine.

19

That’s Apple for you, their guidelines only become rules when the App Store or Code Singing is involved.

20

Update: I have found a hack which seems to work. It turns out that the MachO code inside a framework bundle is, in fact, just a dylib, and you can use this fact to flatten the framework back into a dylib. It requires the use of otool and install_name_tool to fix the dylib paths.

In quick testing it seems to work (e.g. I can make an app, flatten the framework into a dylib, codesign it, and then put it on an ISO and the code signature is still valid).

Since this is a big hack and there may be horrible side effects, I would not recommend using it for shipping products.

Also, I’m running into other problems with ISO file generation, so I may end up dropping the whole ISO idea altogether.