> On Jan 20, 2020, at 1:24 AM, Gabriele Greco <gabrielegr...@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
_______________________________________________
gtk-osx-users-list mailing list
gtk-osx-users-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list
