Not working on Big Sur
kidonng opened this issue · 29 comments
CrashReporter indicates the underlying cause is that highlight cannot use the lua dynamic library as it is not codesigned.
Dyld Error Message:
Library not loaded: /usr/local/opt/lua/lib/liblua.5.3.dylib
Referenced from: /usr/local/bin/highlight
Reason: no suitable image found. Did find:
file system sandbox blocked open() of '/usr/local/opt/lua/lib/liblua.5.3.dylib'
file system sandbox blocked open() of '/usr/local/lib/liblua.5.3.dylib'
file system sandbox blocked open() of '/usr/local/Cellar/lua/5.3.5_1/lib/liblua.5.3.5.dylib'
There's nothing in the full crash log (below) about a code signature being missing or wrong. @ralphrmartin maybe you know more?
I've tried manually signing the lua library, and adding highlight to System Preferences > Security & Privacy > Privacy > Files and Folders
and System Preferences > Security & Privacy > Privacy > Full Disk Access
. No success.
Process: highlight [12343]
Path: /usr/local/Cellar/highlight/3.59/bin/highlight
Identifier: highlight
Version: 0
Code Type: X86-64 (Native)
Parent Process: zsh [12338]
Responsible: quicklookd [7658]
User ID: 502
Date/Time: 2020-11-15 21:00:05.068 +0100
OS Version: macOS 11.0.1 (20B29)
Report Version: 12
Anonymous UUID: 10AF77C7-90FF-05A1-E223-24F865762E71
Sleep/Wake UUID: 24E7E3DB-343A-4322-A838-427B4C7BD906
Time Awake Since Boot: 210000 seconds
Time Since Wake: 13000 seconds
System Integrity Protection: enabled
Crashed Thread: 0
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Termination Reason: DYLD, [0x6] Filesystem Sandbox
Application Specific Information:
dyld: launch, loading dependent libraries
Dyld Error Message:
Library not loaded: /usr/local/opt/lua/lib/liblua.5.3.dylib
Referenced from: /usr/local/bin/highlight
Reason: no suitable image found. Did find:
file system sandbox blocked open() of '/usr/local/opt/lua/lib/liblua.5.3.dylib'
file system sandbox blocked open() of '/usr/local/lib/liblua.5.3.dylib'
file system sandbox blocked open() of '/usr/local/Cellar/lua/5.3.5_1/lib/liblua.5.3.5.dylib'
Binary Images:
0x101a4f000 - 0x101b0efff +highlight (0) <8A359DEB-14EE-3D18-B9AD-03287280B917> /usr/local/bin/highlight
0x10b621000 - 0x10b6bcfff dyld (832.7.1) <2705F0D8-C104-3DE9-BEB5-B1EF6E28656D> /usr/lib/dyld
0x7fff2a505000 - 0x7fff2a506fff libSystem.B.dylib (1292.50.1) <14E3BB7B-B95F-3700-8D12-B9B2012C0AF8> /usr/lib/libSystem.B.dylib
Model: MacBookPro14,1, BootROM 429.50.1.0.0, 2 processors, Dual-Core Intel Core i5, 2.3 GHz, 16 GB, SMC 2.43f10
Graphics: kHW_IntelIrisGraphics640Item, Intel Iris Plus Graphics 640, spdisplays_builtin
Memory Module: BANK 0/DIMM0, 8 GB, LPDDR3, 2133 MHz, 0x802C, 0x4D5435324C31473332443450472D30393320
Memory Module: BANK 1/DIMM0, 8 GB, LPDDR3, 2133 MHz, 0x802C, 0x4D5435324C31473332443450472D30393320
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x170), Broadcom BCM43xx 1.0 (7.77.111.1 AirPortDriverBrcmNIC-1669)
Bluetooth: Version 8.0.1f5, 3 services, 27 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en0
USB Device: USB 3.0 Bus
Thunderbolt Bus: MacBook Pro, Apple Inc., 41.4
Sorry, no perhaps I was jumping to a conclusion. While liblua is not codesigned, that may not be the problem.
Maybe one way to overcome this is to bundle a private copy of highlight and the lua library with QLColorCode?
I'm certainly no expert.
+1
FYI, a similar plugin also has this issue: samuelmeuli/glance#46 (sadly the project is archived)
I attempted to bypass the colorize.sh
file by having colorizeURL()
call highlight
directly. This still gave the same kind of error:
Sandbox: highlight(68145) deny(1) file-read-data /opt/local/lib/liblua.dylib
Violation: deny(1) file-read-data /opt/local/lib/liblua.dylib
Process: highlight [68145]
Path: /opt/local/bin/highlight
Load Address: 0x100296000
Identifier: highlight
Version: ??? (???)
Code Type: x86_64 (Native)
Parent Process: ExternalQuickLookSatellite-x86_ [68143]
Responsible: /System/Library/Frameworks/QuickLook.framework/Versions/A/Resources/quicklookd.app/Contents/MacOS/quicklookd
The only difference is the Parent Process line.
I tested with a binary that has no libraries other than ones signed by Apple and it shows output. So theoretically, a static build of highlight
would work.
I think if I can build highlight
linked with liblua.a
rather than the dylib, this will work.
Other observations
It would be theoretically possible to use a user-provided Pygmentize as long as /usr/bin/python3
is passed as the launchPath
. This relies on a lot of unknowns on a given system and is too difficult to support IMHO.
task.environment = @{@"PYTHONPATH": @"/opt/local/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages", @"TMPDIR": @"/tmp"};
task.launchPath = @"/usr/bin/python3";
task.arguments = @[@"-B", @"/opt/local/bin/pygmentize", @"-f", @"html", targetEsc];
My only issue is that for whatever reason, /usr/bin/python3
cannot write to $TMPDIR
:
python3: error: couldn't create cache file '/var/folders/qv/gnhwyzzx2wqfxq9mm_c4pb3r0000gn/T/xcrun_db-Xek3XirT' (errno=Operation not permitted)
I have added /usr/bin/python3
to Security & Privacy under the Privacy tab, under Development Tools and Full Disk Access. I've also done this with highlight
and had no luck.
I think I've discovered that because of sandbox restrictions, a Quick Look plugin must have all properly signed binaries (even if only ad-hoc) and files it wishes to use within its bundle. In this project that's a highlight binary plus the Lua library it needs and the configuration files it uses.
I did build Highlight (outside of bundle) with a static Lua but then I only ran into a different sandbox error because Highlight needs to read its configuration.
+1 with js files
I'll be working on a patch to include Highlight and Lua in the built bundle.
For my experience I suggest you statically link the lua library in highlight.
I'm not a c programmer but the operation is easy by editing the highlight makefile.
If you need some information, I can tell you how I did for my application.
I'll be working on a patch to include Highlight and Lua in the built bundle.
For my experience I suggest you statically link the lua library in highlight.
I'm not a c programmer but the operation is easy by editing the highlight makefile.
If you need some information, I can tell you how I did for my application.
I've already done this on my own. Whether it's linked statically or not is not going to make a difference here. The macOS sandbox since Big Sur just has more stringent requirements for plugins. It's going to be a lot easier to keep all binaries signed and contained within the bundle. It also makes this package easier to install since having highlight
in PATH
(or setting hlPath
) is not necessary.
I prefer statically so as not to have problems with paths and avoid the OS trying to pass the library installed in the system perhaps by homebrew (unsigned) instead of the one inserted in the application.
qlmanage -p ~/Desktop/server.js
this works on DEBUG mode but on finder it shows white blank page. On console i managed to get this warning message below
/Users/username/Desktop/server.js
2020-11-25 11:19:47.470 qlmanage[16207:105092] could not create directory "/Users/username/Library/Caches/com.apple.quicklook.qlmanage/WebKit/ServiceWorkers" for future sandbox extension, error Error Domain=NSCocoaErrorDomain Code=513 "You don’t have permission to save the file “ServiceWorkers” in the folder “WebKit”." UserInfo={NSFilePath=/Users/username/Library/Caches/com.apple.quicklook.qlmanage/WebKit/ServiceWorkers, NSUnderlyingError=0x7fc0a06aa030 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}
2020-11-25 11:19:47.584 qlmanage[16207:105092] *** CFMessagePort: bootstrap_register(): failed 1100 (0x44c) 'Permission denied', port = 0x14a03, name = 'com.apple.coredrag'
See /usr/include/servers/bootstrap_defs.h for the error codes.
2020-11-25 11:19:47.618 qlmanage[16207:105092] *** CFMessagePort: bootstrap_register(): failed 1100 (0x44c) 'Permission denied', port = 0xbe4b, name = 'com.apple.tsm.portname'
Yes it works on debug because sandbox restrictions are not so strict there (possibly because of you setting Terminal/etc to lessen restrictions in System Preferences - Security & Privacy).
so is there a workaround for quicklook plugins?
At this time not for this one.
Plugins that bundle all of their code properly signed and within the bundle directory will work. This plugin requires highlight to be in PATH so it does not work from Finder where it wants everything properly code signed. Even if you adhoc sign the highlight binary or make it load Lua statically, it still needs to read its configuration file and this isn't going to be sandbox friendly usually.
I am making a patched version of this that will bundle Highlight and its libs and files so this will work again on Big Sur.
I encountered the same issues
It's there. Please try it out.
@anthonygelibert confirming that the pull request by @Tatsh works on BigSur 11.0.1 (20B29)
@ferologics, perhaps you should try to restart the system.
@okalachev works! I guess quick look needed to reload the plug-in.
@anthonygelibert I just tried to verify the plugin on Big Sur and have exactly the same issue as @sourcier in #72 (comment)
looking at Console I'm getting
Couldn't write values for keys (
pathHL
) in CFPrefsPlistSource<0x7f956562a050> (Domain: org.n8gray.QLColorCode, User: kCFPreferencesCurrentUser, ByHost: No, Container: (null), Contents Need Refresh: Yes): setting preferences outside an application's container requires user-preference-write or file-write-data sandbox access
rejecting read of { org.n8gray.QLColorCode, jake, kCFPreferencesAnyHost, /Users/jake/Library/Preferences/org.n8gray.QLColorCode.plist, managed: 0 } from process 48300 (ExternalQuickLookSatellite-x86_) because accessing preferences outside an application's container requires user-preference-read or file-read-data sandbox access
QLColorCode: colorize.sh failed with exit code 101. Command was ('/Users/user/Library/QuickLook/QLColorCode.qlgenerator/Contents/Resources/colorize.sh' '/Users/user/Library/QuickLook/QLColorCode.qlgenerator/Contents/Resources' '/path/to/file.js' 0).
on Big Sur 11.1
looking at Console I'm getting
Couldn't write values for keys ( pathHL ) in CFPrefsPlistSource<0x7f956562a050> (Domain: org.n8gray.QLColorCode, User: kCFPreferencesCurrentUser, ByHost: No, Container: (null), Contents Need Refresh: Yes): setting preferences outside an application's container requires user-preference-write or file-write-data sandbox access rejecting read of { org.n8gray.QLColorCode, jake, kCFPreferencesAnyHost, /Users/jake/Library/Preferences/org.n8gray.QLColorCode.plist, managed: 0 } from process 48300 (ExternalQuickLookSatellite-x86_) because accessing preferences outside an application's container requires user-preference-read or file-read-data sandbox access QLColorCode: colorize.sh failed with exit code 101. Command was ('/Users/user/Library/QuickLook/QLColorCode.qlgenerator/Contents/Resources/colorize.sh' '/Users/user/Library/QuickLook/QLColorCode.qlgenerator/Contents/Resources' '/path/to/file.js' 0).
on Big Sur 11.1
This is a different issue than what this #72 was originally for. The distributed package needs to add more permissions.
If you build locally you probably will not have this issue.
@Tatsh For those of us who don't use XCode much, is there a way to build it locally without the full XCode app (which I happen to not have enough space for right now)?
Solution (on Big Sur) is:
list quarantine files:
xattr -r ~/Library/QuickLook/QL* -d com.apple.quarantine
remove quarantine:
xattr -r -d com.apple.quarantine ~/Library/QuickLook/QL*
then I am able to use space bar to preview/quicklook files (.sh, .sql, etc.)
credits to @neslob (Vielen Dank Nils)
source comment: #51 (comment)