Bug #4479

chirp-daily-20170126 is not launched in OS X Sierra

Added by Erhan Aslanturk over 3 years ago. Updated over 3 years ago.

Status:Closed Start date:02/02/2017
Priority:High Due date:
Assignee:Tim Smith % Done:

100%

Category:-
Target version:-
Chirp Version:daily Platform:MacOS
Model affected:(All models)

Description

I was running chirp-daily-20161220 without problem in OSX Sierra but after that new releases don't open when click on app icon.

Application size was 5.7MB, but newer ones 3MB. There seems something missing in new releases.

Ekran Resmi 2017-02-02 21.50.53.jpg (32.3 kB) Erhan Aslanturk, 02/02/2017 10:51 am


Related issues

duplicated by Bug #4485: Not working Mac OS X 10.12.3 Rejected 02/02/2017
duplicated by Bug #4503: MacOS crash on launch Rejected 02/07/2017

Associated revisions

Revision 2842:4c1697b626b2
Added by Tim Smith over 3 years ago

Fix app launching on OS X #4479

Running chirp .app bundles from ~/Downloads was observed to fail on recent versions of OS X. This is because a OS X security feature called App Translocation is actually executing the .app bundle from a temporary read-only disk image, and the chirp launch script attempts to modify the contents of the app bundle.

This patch avoids modifying the .app bundle when App Translocation is active.

History

Updated by Michel D. over 3 years ago

Erhan Aslanturk wrote:

I was running chirp-daily-20161220 without problem in OSX Sierra but after that new releases don't open when click on app icon.

Application size was 5.7MB, but newer ones 3MB. There seems something missing in new releases.

I have the same problem with Sierra OS X 10.12.3

Updated by Tom Hayward over 3 years ago

I was able to reproduce this, but only once. The first time, I got this error:

open chirp-daily-20170126.app
LSOpenURLsWithRole() failed with error -10810 for the file /Users/tom/Downloads/chirp-daily-20170126.app.

Then I ran:

cd chirp-daily-20170126.app/Contents/MacOS/
./chirp

And it started right up.

Now when I use open or double-click the app, it starts normally.

My hunch is that this has something to do with macOS security protections. Since it works fine once you get past this step, it's apparently not missing anything.

Updated by Michel D. over 3 years ago

Tom Hayward wrote:

I was able to reproduce this, but only once. The first time, I got this error:

[...]

Then I ran:

[...]

And it started right up.

Now when I use open or double-click the app, it starts normally.

HI,

Same here, now it runs.

Updated by Erhan Aslanturk over 3 years ago

Yes, following works fine but its a little bit proficient action to have it running. Average Mac users may not do that.

cd chirp-daily-20170126.app/Contents/MacOS/
./chirp

Updated by jim k over 3 years ago

I experienced this difficulty also - brand new to CHIRP, Sierra 10.12.2. navigating to the folder as per the above and
sudo ./chirp
got me launched.

I'm too new and inexperienced to be editing the project's documentation, but perhaps this approach could be noted on the wiki; reordering http://chirp.danplanet.com/projects/chirp/wiki/MacOS_Tips so the current os x version is at the top and better called out as 'hey we have to do weird stuff to appease apple security folk' would be better. I almost gave up after attempting several old install packages, and stumbled on #4485 then found this thread/approach.

Looking forward to coming up to speed with CHIRP.

Updated by Tim Smith over 3 years ago

  • Target version deleted (0.4.1)
  • Chirp Version changed from 0.4.0 to daily

I think the startup script is causing a sandbox violation that's keeping the app from opening when it tries to symlink the Python framework into the app bundle (so that argv[0] is pretty). Running it from the command line solves the problem because it runs outside the application sandbox. Once the symlink is created, subsequent runs within the app sandbox work fine.

Removing this code from Contents/MacOS/chirp solves the problem:

if [ -x $PYTHON ]; then
    ln -s $PYTHON "${LOCATION}/../CHIRP" 
    PYTHON=${LOCATION}/../CHIRP
    export PYTHONPATH="/opt/kk7ds//Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/" 
else
    PYTHON=/opt/kk7ds/bin/python2.7
fi

(but makes argv[0] ugly, so the About menu etc have "Python" instead of "CHIRP".)

Updated by Tim Smith over 3 years ago

It looks like https://stackoverflow.com/questions/14122330/programatically-setting-the-mac-menubar-title offers a solution using ctypes and undocumented APIs...

Updated by Richard Perlman over 3 years ago

As reported in Bug #4503, The core issue seems to relate to the directory chirp is located in when it is first run. If run from a location other than "Applications" it fails with an error 126. After being moved into "Applications" it starts normally and can then be re-copied elsewhere.

Updated by Tim Smith over 3 years ago

After a little testing it looks like if it's been moved to /Applications, then the app bundle will always run the first time and can have any name at all. If the app sandbox has different rules for /Applications than e.g. ~/Downloads, that would be consistent with the behavior you're observing; I don't see anything Chirp-specific that asserts that it's being opened from a particular location.

Aha: it looks like we're observing a behavior called "App Translocation" or "Gatekeeper Path Randomization" that applies to quarantined apps run from ~/Downloads. I was a little wrong insofar as it's not a "sandbox" but it does run apps from a temporary read-only volume, which explains why the initialization code that attempts to write into the app bundle causes the app to crash.

This is described at https://weblog.rogueamoeba.com/2016/06/29/sierra-and-gatekeeper-path-randomization/, http://mjtsai.com/blog/2016/06/16/gatekeeper-path-randomization/... and almost not at all on developer.apple.com.

Updated by Tim Smith over 3 years ago

Chirp can check whether it's being run from a translocated location. Chirp should only attempt the pretty-name hack if it is not translocated.

  • security translocate-status-check some_path will print either "TRANSLOCATED" or "NOT TRANSLOCATED" if translocate-status-check is supported.
  • Given an unknown command (as on older versions of OS X, presumably), security prints security: unknown command "asdf".

This patch tries to add that check:

diff --git a/Contents/MacOS/chirp b/Contents/MacOS/chirp
index 5386485..dab4777 100755
--- a/Contents/MacOS/chirp
+++ b/Contents/MacOS/chirp
@@ -4,7 +4,11 @@ LOCATION=$(dirname "${BASH_SOURCE}")

 PYTHON=/opt/kk7ds//Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python

-if [ -x $PYTHON ]; then
+not_translocated () {
+    security translocate-status-check "$LOCATION" 2>&1 | grep -q -e NOT -e unknown -e "not found" 
+}
+
+if [ -x $PYTHON ] && not_translocated; then
     ln -s $PYTHON "${LOCATION}/../CHIRP" 
     PYTHON=${LOCATION}/../CHIRP
     export PYTHONPATH="/opt/kk7ds//Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/" 

Updated by Tim Smith over 3 years ago

  • Status changed from New to In Progress
  • Assignee set to Tim Smith
  • % Done changed from 0 to 100

The next daily (20170209 or later) incorporates a fix.

Updated by Tim Smith over 3 years ago

  • Status changed from In Progress to Closed

Closing as fixed.

Updated by RJ Anderson over 3 years ago

Hi, Just got chrip 20170518 build, OSX 10.12.5. App will not open at all (even from Applications). Tried all above. Still won't open (double click launches something which exits immediately without any UI or error). Thx.

Updated by RJ Anderson over 3 years ago

RJ Anderson wrote:

Hi, Just got chirp 20170518 build, OSX 10.12.5. App will not open at all (even from Applications). Tried all above. Still won't open (double click launches something which exits immediately without any UI or error). Thx.

Updated by RJ Anderson over 3 years ago

I get this if this is helpful:
Last login: Fri May 19 14:54:21 on ttys000
Robs-Imac-Retina-2:~ robertanderson$ /Applications/Chirp.app/Contents/MacOS/chirp ; exit;
/Applications/Chirp.app/Contents/MacOS/chirp: line 19: /opt/kk7ds/bin/python2.7: No such file or directory
/Applications/Chirp.app/Contents/MacOS/chirp: line 19: exec: /opt/kk7ds/bin/python2.7: cannot execute: No such file or directory
logout
Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.

[Process completed]

but no application window ever shows. It looks like it's not finding "Python 2.7", although I downloaded and installed that explicitly, but that didn't help. thx

Updated by RJ Anderson over 3 years ago

Resolved, apparently, there are multiple Python 2.7 downloads out there, the only one that this seems to work with is: http://www.d-rats.com/download/OSX_Runtime/KK7DS_Python_Runtime_R10.pkg
Installing that fixed the issue.

Updated by Jim Unroe over 3 years ago

RJ Anderson wrote:

Resolved, apparently, there are multiple Python 2.7 downloads out there, the only one that this seems to work with is: http://www.d-rats.com/download/OSX_Runtime/KK7DS_Python_Runtime_R10.pkg
Installing that fixed the issue.

I'm glad you got it resolved. It does tell you to install that package in the MacOS Users section of the CHIRP download page (quoted below).

  • New Mac OS X must install the runtime once before running CHIRP. After it is installed, the runtime does not need to be downloaded or installed each time. Download the KK7DS Python runtime for Mac OSX.

Jim

Also available in: Atom PDF

prevent spam