Huh, I suppose it's possible optool doesn't work properly in High Sierra. If so, you might try in a Mavericks VM, since I know for sure it works there. You could also try recompiling it on High Sierra, or installing it from MacPorts on High Sierra.
Interesting that MacPorts seems to have an optool build for Mountain Lion (Darwin 12), so I can probably add back the Dictionary fix there at least.
http://packages.macports.org/optool/
@Wowfunhappy --
Problem solved!!! I found a reliable way to strip the digital signatures from the Dictionary.app in Lion!
Please note that there are many ways to strip digital code signatures (or code signing) from Mac binaries but only a few work on Lion:
Option 1 - "codesign" -- codesign comes with Lion. (I believe it first appeared in Snow Leopard). There is an undocumented flag called "--remove-signature" which will, as the name suggests, remove code signatures. Unfortunately, it did not work on the Dictonary.app in Lion
Code:
codesign --remove-signature /Users/grinch/Desktop/TEST/Dictionary.app
/Users/grinch/Desktop/TEST/Dictionary.app: unsupported type or version of signature
P.S.
One can use the "codesign" tool built-in to Mac OS to display or verify a binary's digital code signature. I use it to see if the code signature was actually removed! (e.g. codesign --display --verbose {path to binary}. Note you can get even more info using -- codesign --display --verbose=4 {path to binary} ).
Option 2 - "optool" -- As you know "optool" will remove digital code signatures from binaries but it does NOT run or even compile on Lion.
Note: "optool" is NOT reliable. Sometimes it corrupts the binary whose digital code signature has been stripped. In my case, running "optool" on High Sierra corrupted the Dictionary.app binary from Lion.
I also noticed that even when it did not corrupt the binary, "optool" really did not strip the digital signature fully. Here is the output from "codesign --display" on mavericks28's modified Lion Dictionary.app after optool's stripped the digital signature:
Code:
codesign --display --verbose /Applications/Dictionary\ Proxied.app /Applications/Dictionary Proxied.app: invalid signature (code or signature have been modified)
It is interesting to note that maericks28's modified Dictionary.app still runs just fine on Lion and uses the squid https proxy even though the digital signature appears to be invalid!
Option 3 - "stripcodesig" -- This command line tool will also strip digital code signatures from Mac binaries. But it appears to crash on Lion.
(For source, see
https://github.com/tvi/stripcodesig. For Binaries, see
http://www.jackoverfull.com/print.php?news=1489678895-en )
Option 4 - "xattr" -- One can use "xattr" to strip digital code signatures which are part of the binary's extended attributes. (e.g. xattr -c {path to binary file} ). Or you can strip all extended attributes from an application bundle. (e.g. xattr -cr {path to app bundle.app}.
But please note that the process of codesigning a binary often modifies NOT ONLY the extended attributes of a binary BUT ALSO the binary itself! But in many cases, the "xattr" tool will do the trick when trying to get around code signing issues.
After using "xattr" on Lion, the modified Dictionary.app still ran just fine but I was not able to get it to use your squid https proxy. Another failure.
Option 5 - "insert_dylib" - "insert_dylib" is a command line utility for inserting a dylib load command into a Mach-O binary. (See
https://github.com/Tyilo/insert_dylib#removing-code-signature ). I really though that this would do the trick! The source compiles on Lion and even runs. But it does not appear to work!
Option 6 - "unsign" -- SUCCESS!!! -- "Unsign" compiles and runs on Lion, and unlike "optool", it appears to really strip the digital signature from Lion Mac binaries!! (see
https://github.com/steakknife/unsign for the source which compiles on Lion. If you need the binary, PM me).
Code:
grinch$ ./unsign Dictionary.app/Contents/MacOS/Dictionary
reading infile: Dictionary.app/Contents/MacOS/Dictionary
processing fat architecture 1 of 2
found LC_CODE_SIGNATURE
processing fat architecture 2 of 2
found LC_CODE_SIGNATURE
wrote outfile: Dictionary.app/Contents/MacOS/Dictionary.unsigned
After using unsign, the digital code signature is REALLY removed!
Code:
grinch$ codesign --display --verbose /Users/grinch/Desktop/TEST/Dictionary.app
/Users/grinch/Desktop/TEST/Dictionary.app: code object is not signed at all
I was successfully able to create a new and improved Dictionary.app using unsign and your instructions. But please note, one MUST use "unsign" to strip the digital signature AFTER you have inserted ProxyFix.dylib into /Contents/Frameworks and after adding the LSEnvironment key. (I tried using "unsign" first and then adding ProxyFix.dylib etc. The modified Dictionary.app ran just fine but it would not use the squid https proxy! Please do not ask me why!)
Note: the "unsign" tool creates a binary with the following file name extension -- ".unsigned". You will need to rename the resulting binary etc.
So if you want to provide updated Dictionary binaries for Lion users in your https proxy package, you may want to try using "unsign" instead of "optool".
P.S. I have not tested using "unsign" etc on Mountain Lion yet but I suspect it will work just fine.
