Re: [macOS] Notarization, hardened runtimes, LCB, and executables
On Thu, Feb 6, 2020 at 3:22 PM panagiotis merakos via use-livecode < use-livecode@lists.runrev.com> wrote: > Very useful post Trevor, thank you. > > Can you confirm that the notarized standalone does NOT open in Mac OSX > 10.9-10.11? > I have a 10.10 VM. I just tested the app I notarized and it worked fine. -- Trevor DeVore ScreenSteps www.screensteps.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: [macOS] Notarization, hardened runtimes, LCB, and executables
Very useful post Trevor, thank you. Can you confirm that the notarized standalone does NOT open in Mac OSX 10.9-10.11? I could not find this info in the Apple official docs, but I believe this is the case. Unfortunately my old mac that ran OSX 10.10 has been upgraded to High Sierra, so I cannot test it myself. Kind regards, Panos On Thu, Feb 6, 2020, 21:52 Trevor DeVore via use-livecode < use-livecode@lists.runrev.com> wrote: > On Thu, Feb 6, 2020 at 12:12 PM David V Glasgow via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > I have to say that this fills me with despair. I try hard to write > > serious, useful programs, for fellow professionals, but I am not a > > developer by trade or training. I have a full time job, which subsidises > > my time using LC > > > > The beauty of LC (and Metacard before it) has always been how amazingly > > easy it is to write something genuinely useful and share it with others, > > pretty much irrespective of platform. I used to just share with > colleagues > > via DropBox. > > > > Now I look at an app I have developed and realise I have neither the time > > or technical ability to navigate through certification and notarization. > > > > Is this the beginning of the end for enthusiast developers? > > > > I don't see a reason why these new complexities (at least most) can't be > hidden from most users. LC already hides all sorts of things from us that > we don't want to know anything about. Code signing and entitlements aren't > tricky problems to address, at least once you understand the problem. But > it will take time to do the research, design a UI, hook up the UI, and > write the underlying code. > > -- > Trevor DeVore > ScreenSteps > www.screensteps.com > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: [macOS] Notarization, hardened runtimes, LCB, and executables
On Thu, Feb 6, 2020 at 12:12 PM David V Glasgow via use-livecode < use-livecode@lists.runrev.com> wrote: > I have to say that this fills me with despair. I try hard to write > serious, useful programs, for fellow professionals, but I am not a > developer by trade or training. I have a full time job, which subsidises > my time using LC > > The beauty of LC (and Metacard before it) has always been how amazingly > easy it is to write something genuinely useful and share it with others, > pretty much irrespective of platform. I used to just share with colleagues > via DropBox. > > Now I look at an app I have developed and realise I have neither the time > or technical ability to navigate through certification and notarization. > > Is this the beginning of the end for enthusiast developers? > I don't see a reason why these new complexities (at least most) can't be hidden from most users. LC already hides all sorts of things from us that we don't want to know anything about. Code signing and entitlements aren't tricky problems to address, at least once you understand the problem. But it will take time to do the research, design a UI, hook up the UI, and write the underlying code. -- Trevor DeVore ScreenSteps www.screensteps.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: [macOS] Notarization, hardened runtimes, LCB, and executables
I know how you feel. But I'm hoping the LC team will help us out with this, they surely know the complexities. I'm looking forward to a standalone builder that will relieve the stress that Apple puts on its developers. On 2/6/20 12:11 PM, David V Glasgow via use-livecode wrote: I have to say that this fills me with despair. I try hard to write serious, useful programs, for fellow professionals, but I am not a developer by trade or training. I have a full time job, which subsidises my time using LC The beauty of LC (and Metacard before it) has always been how amazingly easy it is to write something genuinely useful and share it with others, pretty much irrespective of platform. I used to just share with colleagues via DropBox. Now I look at an app I have developed and realise I have neither the time or technical ability to navigate through certification and notarization. Is this the beginning of the end for enthusiast developers? Best wishes, David Glasgow On 6 Feb 2020, at 5:22 pm, Trevor DeVore via use-livecode wrote: On Thu, Feb 6, 2020 at 10:23 AM Trevor DeVore wrote: After packaging up the app I did a quick test to make sure the new feature worked on my machine. It didn't. The error message was about some code trying to execute that wasn't signed and some note about library validation or something or other (I didn't write it down). Actually, I did capture the error: [13283] Error loading Python lib '/var/folders/px/g8hg_x_10697wwmdb9t3thd4gn/T/_MEIT0IjWA/Python': dlopen: dlopen(/var/folders/px/g8hg_x_10697wwmdb9t3thd4gn/T/_MEIT0IjWA/Python, 10): no suitable image found. Did find: /var/folders/px/g8hg_x_10697wwmdb9t3thd4gn/T/_MEIT0IjWA/Python: code signature in (/var/folders/px/g8hg_x_10697wwmdb9t3thd4gn/T/_MEIT0IjWA/Python) not valid for use in process using Library Validation: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed. -- Trevor DeVore ScreenSteps www.screensteps.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: [macOS] Notarization, hardened runtimes, LCB, and executables
I have to say that this fills me with despair. I try hard to write serious, useful programs, for fellow professionals, but I am not a developer by trade or training. I have a full time job, which subsidises my time using LC The beauty of LC (and Metacard before it) has always been how amazingly easy it is to write something genuinely useful and share it with others, pretty much irrespective of platform. I used to just share with colleagues via DropBox. Now I look at an app I have developed and realise I have neither the time or technical ability to navigate through certification and notarization. Is this the beginning of the end for enthusiast developers? Best wishes, David Glasgow > On 6 Feb 2020, at 5:22 pm, Trevor DeVore via use-livecode > wrote: > > On Thu, Feb 6, 2020 at 10:23 AM Trevor DeVore > wrote: > >> >> After packaging up the app I did a quick test to make sure the new feature >> worked on my machine. It didn't. The error message was about some code >> trying to execute that wasn't signed and some note about library validation >> or something or other (I didn't write it down). >> > > Actually, I did capture the error: > > [13283] Error loading Python lib > '/var/folders/px/g8hg_x_10697wwmdb9t3thd4gn/T/_MEIT0IjWA/Python': > dlopen: > dlopen(/var/folders/px/g8hg_x_10697wwmdb9t3thd4gn/T/_MEIT0IjWA/Python, > 10): no suitable image found. Did find: > /var/folders/px/g8hg_x_10697wwmdb9t3thd4gn/T/_MEIT0IjWA/Python: code > signature in > (/var/folders/px/g8hg_x_10697wwmdb9t3thd4gn/T/_MEIT0IjWA/Python) not > valid for use in process using Library Validation: mapped file has no > cdhash, completely unsigned? Code has to be at least ad-hoc signed. > > -- > Trevor DeVore > ScreenSteps > www.screensteps.com > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: [macOS] Notarization, hardened runtimes, LCB, and executables
On Thu, Feb 6, 2020 at 10:23 AM Trevor DeVore wrote: > > After packaging up the app I did a quick test to make sure the new feature > worked on my machine. It didn't. The error message was about some code > trying to execute that wasn't signed and some note about library validation > or something or other (I didn't write it down). > Actually, I did capture the error: [13283] Error loading Python lib '/var/folders/px/g8hg_x_10697wwmdb9t3thd4gn/T/_MEIT0IjWA/Python': dlopen: dlopen(/var/folders/px/g8hg_x_10697wwmdb9t3thd4gn/T/_MEIT0IjWA/Python, 10): no suitable image found. Did find: /var/folders/px/g8hg_x_10697wwmdb9t3thd4gn/T/_MEIT0IjWA/Python: code signature in (/var/folders/px/g8hg_x_10697wwmdb9t3thd4gn/T/_MEIT0IjWA/Python) not valid for use in process using Library Validation: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed. -- Trevor DeVore ScreenSteps www.screensteps.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
[macOS] Notarization, hardened runtimes, LCB, and executables
Hey list, I just spent a good portion of the last few days troubleshooting some notarization errors I started receiving. I'm going to document what I did so that someone else out there might benefit. # The Original Problem I have been notarizing my application for a while now without any issues. This week an error message started coming back from Apple: "The executable does not have the hardened runtime enabled.". (I found the error my looking at the log file that Levure creates when packaging an application. It contains the responses from the Apple notarization service which in turn contain a url pointing to a detailed report of why an app fails notarization.) A search led me to the following web page which tells me to pass the `--options=runtime` to the `codesign` command line call to fix this issue. https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution/resolving_common_notarization_issues?language=objc Easy enough. I updated the Levure packager script (see links below) that packages up applications so that it will automatically sign the app bundle and the files inside using this option as part of the packaging process. I ran into some problems when trying to sign the Sparkle.framework that ships with my app. It has an Autoupdate.app app inside of the `./Content/Resources` folder which in turn contains a `filop` executable that wasn't being signed. I had to spend some time making additional improvements to the Levure packager script so that it would dig down into the necessary folders looking for files that need signing. After making the necessary changes so that all files were properly signed application was successfully notarized by Apple. Phew! # The Problem Caused By The Solution To The Problem Unfortunately the solution of hardening the runtime uncovered yet another problem. My application started throwing an error when trying to load some LCB code. The LiveCode engine was unable to bind to some Foreign Function Interface definitions in one of my LCB files. The problematic binding is defined as follows: private foreign handler C_CurrentKbdLayoutInputSource() returns ObjcId binds to "c:Carbon.framework>TISCopyCurrentKeyboardLayoutInputSource" # Entitlements Since none of my code had changed I looked in the Console application to see if there were any error messages. I saw a message in the console about my app needing the `com.apple.security.automation.apple-events` permission so I chased that red herring for a while. As part of my research I came across entitlements. Entitlements are a way for you to tell macOS that your app needs special permissions. I've used them before in the Mac App Store but not for apps used outside the store. The following web page lists the entitlements that are available for a macOS app: https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_disable-library-validation?language=objc As I scanned through the list a couple of the options caught my eye. For instance, `com.apple.security.cs.allow-dyld-environment-variables` sounds like something that might apply to LCB. My first test involved assigning a number of entitlements to my app to see if it would launch. Sure enough it did. I then started removing entitlements until I found the smallest list that would work. Here is the final entitlement file that I came up with that allowed my LCB code to run without causing an error or causing a spinning beach ball of doom: http://www.apple.com/DTDs/PropertyList-1.0.dtd;> com.apple.security.cs.allow-unsigned-executable-memory com.apple.security.cs.allow-dyld-environment-variables The above XML goes in a file with the same name as my app with an `.entitlements` extension. That file is added to the `./Contents/Resources` folder of the app bundle and Levure then uses that file when signing the app. Learn more: https://github.com/trevordevore/levure/wiki/How-do-I-include-additional-files-and-folders-in-my-application-builds%3F#copy-files-into-the-contentsresources-folder-of-your-packaged-macos-application This same entitlements file also fixed a problem I was seeing with the browser widget in my app. It too would lock up. # Mostly Smooth Sailing With a hardened runtime and the proper entitlements in place my LiveCode app was being notarized successfully AND launching. Good times! Feeling confident I decided to merge in a branch I had been working on that included an executable created using pyinstaller so I could send it off to QA. That didn't go well. After packaging up the app I did a quick test to make sure the new feature worked on my machine. It didn't. The error message was about some code trying to execute that wasn't signed and some note about library validation or something or other (I didn't write it down). After some searches I found some other people who experienced similar problems with executables built with pyinstaller (and some other installers I believe).
