Package app for distribution?

[gkovacsds]

Hello, first big thanks for all the efforts with Wineskin. My problem: I've been trying to package a windows app with Wineskin so that it passes Gatekeeper and ready for distribution, but the problem is that it won't launch anymore after all the packaging steps. I've codesigned a huge number of executables, so's, dylib's, the nested .app's that notarization complained for. Then made a pkg. It passed Apple notarization, I stapled it, but after installing the pkg, the resulting app won't start. I tried on a clean Mac too to avoid app and package cache/registration issues. Anyone successfully managed to do this?

[gkovacsds]

To be clear, I meant to codesign, package, notarize, staple and distribute a wineskin wrapper / bottle. And we have active Apple Developer certificates.

[gkovacsds]

Seems like the problem is that the wine executables can't have the hardened runtime enabled. If I codesign them with --options runtime then they don't execute anymore. But without hardened runtime, notarization fails. If anyone has a solution, it's welcome.

[emendelson]

I tried to find a solution for this long ago; there isn't one. The best thing I can think of is to create a notarized Applescript app that runs the xattr -rc command (or something similar) on the app. That method works on my machine, but I haven't tried uploading the Applescript app for for anyone else to use.

[Gcenx]

I’m currently at work but wine requires a number of entitlements, the breakage is lightly directly related to the lack of these.

[gkovacsds]

I added the 7 entitlements that Crossover has on their wine binaries and it now runs on the development machine, but not on another. With xattr -rc it starts there too, but strangely no texts can be seen on the window. Packaging seems to do some strange file permission problems too after installing. Taking a break now...

[emendelson]

Well, this sounds at least hopeful. Can you share the entitlements.plist that Crossover uses? I would be grateful for a chance to try this here.

[gkovacsds]

Sure it's here: https://drive.google.com/file/d/1emQ6bmAGFTuJ1XO04jErI-GI9u2GBZlD/view?usp=sharing

[gkovacsds]

I applied it to all files in wine bin...maybe not all of them needs it, but that's out of my knowledge: find "$APPDIR/$APP.app/Contents/SharedSupport/wine/bin" -perm +111 -execdir codesign -v -s "$CODESIGNID" --options runtime --timestamp --entitlements "$(pwd)/wine.entitlements" {} \;

[emendelson]

Thank you - I'll try it with my project and will report any success.

[gkovacsds]

Actually I've found a method of bundling Wineskin bottles passing notarization etc. Without the need to use entitlements and changing the Wineskin bottle. If you share your email address, I can describe it in an email.

[emendelson]

Is there any reason not to post the method here so that everyone can benefit?

[gkovacsds]

I'm happy to share it, my only concern is that Apple might keep an eye on it and not allow such a hack-ish installation of an app in the future. Anyway their protections should catch any wrongdoing software. Ours is nothing like that. And I’ve seen such practice on Windows too where for example Chrome installed its updates to a writeable folder and runs from there. The main idea is that you have a 2 layered app - a wrapper and the real wineskin app. The wrapper contains an installer/launcher and an encoded zip of the wineskin bottle (.app) in the Resources folder. As it's encrypted the content is unknown (I used a simple XOR encoded zip), it will pass notarization. I programmed the wrapper app executable in Freepascal/Lazarus really quickly - it’s really good for people coming from Windows… so, first zip your wineskin .app bottle, encode it and name the encoded app “data” or anything. Put it to the wrapper app bundle Resources, code sign the wrapper app, package, notarize, staple. You can put it on the web and download/install - not banned. Package installs to /Applications - as you launch it, first it will decode the data file, unzip it to the user/Library/“Application Support/Your app name” dir. Then it executes its main executable (…Application Support/App name/xy.app/Contents/MacOS/wineskinlauncher ) from there. In my case it started with a one time update of the wine prefix, then the windows executable starts. When the wrapper app is run next time, it should check if the main app with wineskinlauncher already exists and not unzip again. That’s it in principle. I made a shell script to do all the the packaging, plist mods, notarization etc. but it’s custom for our case. It can take quite a time until it all succeeds, and you don’t want to do it many times (upload 430Mb for notarization...) - so you can even supply a general windows installer in the wineskin bottle, that downloads the windows app, does updates etc. I hope this makes sense, there can be details (chmods, post install script) you may need to do, but it depends on your scenario I think.

[emendelson]

@gkovacsds - That's very clever, and in fact I do something like it with one of my AppleScript applications: it contains a password-protected zip file that gets extracted when the program runs. Apple gives a warning about the zip file when I notarize the application, but continues to notorize it.

Thank for this idea. It should be easy to put into effect with the AppleScript apps that I maintain, and any expert programmer will be able to do a lot more with the idea.

[andreaplanet]

I have the same issue. Notarization works. Hardening wine64-preloader is the issue. I can set hardening (options runtime with entitlements) for all available libraries and runtimes within the app but not for wine64-preloader. For some applications it works, for example if the startup application is the windows notepad.exe. So this maybe could be solved in the future somehow.

We have two workarounds, one is to remove the quarantine flag, the other is to copy the real unsigned App into the Application Support folder and start it from there (without the quarantine flag).

A third workaround could be to move only the SharedSupport\Logs and SharedSupport\Prefix Folder outside the App. Doing so, it would be possible to sign the app which never gets modified and so it could become an Application from an Identified Developer. If someone rights now is able to notarize and run the wrapper, at the first successful run the contents of the prefix folder will be modified, invalidating the signature.

The Prefix/Log folder could be extracted into the Application Support folder at the first run of the App.

[Gcenx]

I have the same issue. Notarization works. Hardening wine64-preloader is the issue. I can set hardening (options runtime with entitlements) for all available libraries and runtimes within the app but not for wine64-preloader. For some applications it works, for example if the startup application is the windows notepad.exe. So this maybe could be solved in the future somehow.

I believe hardened runtime is only required for MASS and wine wrappers wouldn’t be eligible for MASS. This may have changed but if that’s the case I’ll need to ask Marzent how he’d managed to code-sign and notarize ff-wine I’ve built that’s being used in “FFXIV on Mac”

We have two workarounds, one is to remove the quarantine flag, the other is to copy the real unsigned App into the Application Support folder and start it from there (without the quarantine flag).

That’s a very easy way to handle things and would allow easily upgrading the “port” without hassle.

Heroic Games Launcher for example directly downloads my wine-crossover package and uses it internally when CrossOver isn’t detected. It’s also able to make use of any Wineskin “port” that’s available inside ~/Applications/Wineskin

A third workaround could be to move only the SharedSupport\Logs and SharedSupport\Prefix Folder outside the App. Doing so, it would be possible to sign the app which never gets modified and so it could become an Application from an Identified Developer. If someone rights now is able to notarize and run the wrapper, at the first successful run the contents of the prefix folder will be modified, invalidating the signature.

That would simply turn Wineskin into a launcher instead of being a self contained “port”

The Prefix/Log folder could be extracted into the Application Support folder at the first run of the App.

My intention was always to go with this, I say was as I’m doing everything solo.