Re: [gtk-osx-users] macOS Catalina’s new security features versus GTK.

[John Ralls <jralls ceridwen us>]

> On Jan 20, 2020, at 1:24 AM, Gabriele Greco <gabrielegreco gmail com> wrote:
>
>
>
> Catalina won't let you have a bundle that runs a program that's not in the bundle, nor will it allow a 
> bundled program to dyld libraries outside of the bundle and not in the system library directories. (You can 
> dlopen outside libraries from pre-specified locations if you use the plugins entitlement when code signing 
> the bundle, but that's a bit different.)
>
> The simplest path forward is to use gtk-mac-bundler.
>
> ... did the codesign option in the bundler works correctly now? At the moment I'm still doing something 
> like:
>
> gtk-mac-bundler app.bundle
> find installers/myapp.app -name *.dylib -exec codesign [...];
>
> find installers/myapp.app -name *.so -exec codesign[...];
> codesign -vvv --deep --force --options runtime --strict [...]
> dmgbuild -s dmg_setup.py "MyApp $(VERSION)" installers/MyApp-$(VERSION).dmg
> codesign [...] installers/MyApp-$(VERSION)
> .dmg
>
>
>
> ... to have a DMG that passes the notarization process.
>
> I'm not sure if his problem may be related, but it's possible that a not notarized/stapled binary cannot 
> request at all "unlocking" access to certain path locations?

Gabry,

I haven't yet added --timestamp or --options runtime to the bundler script. There's also a requirement that 
code signing happens with Xcode 10, so when I do it will need a version check. Since there are still issues 
with building on a newer system with macOS-x-min-required set earlier and actually running on earlier if one 
wants to support earlier one should build on it; that means moving the bundle to a 10.14 or later machine and 
re-signing anyway.

I don't think that Pascal has gotten far enough to worry about notarization: His not-really-a-bundle wouldn't 
pass no matter how he signs it.

Regards,
John Ralls