Bookstore

Recent

Author Topic: Signing applications ... trouble with embedded command-line tool  (Read 1547 times)

Hansaplast

  • Hero Member
  • *****
  • Posts: 585
  • Tweaking4All.com
    • Tweaking4All

I've been trying to get this to work for 2 days now, searching all over the Internet trying to find an answer, so I hope someone here can help me out with this one.
I'm compiling under macOS High Sierra, with Lazarus 2.1.0 from SVN, and I sign and test the application under macOS Mojave.
I have an application, 64bit Cocoa, that uses a command-line tool that analyzes a given file (using TProcess).
I do not intend to have this in the Apple App Store, but I do use entitlements/sandboxing, and I have a valid Apple Developers signature ("Developer ID Application: <myname> (<myID>)").


The file structure:


Code: [Select]
MyApp.app/
   Contents/
      Info.plist
      MacOS/  <-- main executable and command-line tool here
      Resources/


The executable and command-line tool (per Apple recommendations) are located in the "MacOS" directory.
At first I tried simply signing the entire bundle, which worked, however calling the command-line tool from the application shows an error in Console (I'm able to pinpoint it to calling the command-line tool);
Code: [Select]
nw_path_close_fd Failed to close guarded necp fd 7 [9: Bad file descriptor]

Debugging a signed application seems challenging at best, and Phil's excellent documentation has been verify helpful, but does not answer my problem.
The application can find the command-line executable just fine, and it works just fine without sandboxing.


After that attempt (and a new recompile) I've signed the command-line with these entitlements.
I did first remove the application from "Applications", removed the matching directory from "/Users/hans/Library/Containers/" and did a reboot (it appears macOS doesn't always refresh what it know of a given application - suggestions on how to do this easier are most welcome).
Code: XML  [Select]
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
  3. <plist version="1.0">
  4. <dict>
  5.     <key>com.apple.security.app-sandbox</key>
  6.     <true/>
  7.     <key>com.apple.security.inherit</key>
  8.     <true/>
  9. </dict>
  10. </plist>


and the application bundle with:
Code: XML  [Select]
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
  3. <plist version="1.0">
  4. <dict>
  5.     <key>com.apple.security.app-sandbox</key>
  6.     <true/>
  7.     <key>com.apple.security.files.user-selected.read-write</key>
  8.     <true/>
  9.     <key>com.apple.security.files.downloads.read-write</key>
  10.     <true/>
  11. </dict>
  12. </plist>
  13.  


But this produces the same error.
I know it's good practice to have the developer sign the application, but that's just not happening with this one.


Using verification, produces:


Code: Bash  [Select]
  1. $ codesign --verify --verbose=4 MyApp.app
  2. --prepared:/Users/hans/Dropbox/Projects/Lazarus Projects/MyApp/Distribution/MyApp.app/Contents/MacOS/tool
  3. --validated:/Users/hans/Dropbox/Projects/Lazarus Projects/MyApp/Distribution/MyApp.app/Contents/MacOS/tool
  4. MyApp.app: valid on disk
  5. MyApp.app: satisfies its Designated Requirement
  6.  


and


Code: Bash  [Select]
  1. $ spctl --assess --verbose RenameMyTVSeries.app
  2. RenameMyTVSeries.app: accepted
  3. source=Developer ID
  4.  


Trying to Google what this error may mean has resulted in no good explanation or any details.
Anyone any suggestions?