“codesign”

[quote='825773022, jsflack, /thread/774781?answerId=825773022#825773022, /profile/jsflack'] I'm wondering if that's a clue? [/quote] Not really. The Finder info is a 32-byte binary data structure. For files, the first field is the traditional Mac OS type type, where 'TEXT' is the type used for text files. The exactly structures are defined in Finder.h, part of the Core Services framework in the macOS SDK. In your hex dump all the bytes are zero except for the one at offset 0x08. That’s the first byte of the finderFlags field. The value, 0x2000, corresponds to the bundle flag (kHasBundle). you can set or clear this using SetFile: % xattr MyTrue.app % SetFile -a B MyTrue.app % xattr MyTrue.app com.apple.FinderInfo % xattr -px com.apple.FinderInfo MyTrue.app 00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 % SetFile -a b MyTrue.app % xattr MyTrue.app Which brings me back to my original point. This is not being set by accident. Something in your build process is deli

[quote='774832021, jan-dev, /thread/774832, /profile/jan-dev'] Or are there alternatives for signing MachO binaries without codesign? [/quote] No. Well, no supported alternatives. The on-disk format used by code signing format is subject to change. If you search around on the ’net you’ll find that folks reverse engineered it, but we don’t support such endeavours. [quote='774832021, jan-dev, /thread/774832, /profile/jan-dev'] perform signing using codesign in a system that runs as LaunchDaemon. [/quote] The only winning move is not to play (-: A launchd daemon runs as root, and signing code as root is always problematic. We even call that out in Creating distribution-signed code for macOS. I’ve seen various folks try to work around this, but that doesn’t end well IME. Specifically, using the UserName property in your launchd property list is not a good option, because it results in your daemon running in a mixed execution context [1]. You should set up your CI server to sign code as a logged

Thanks for helping out with this! So Xcode is running: codesign --verbose=4 --force --sign - /Users/julianflack/Desktop/School_Code/DSP/Projects/GRANNY_SMITH/Builds/MacOSX/build/Debug/GRANNY_SMITH.vst3 and in return: /Users/julianflack/Desktop/School_Code/DSP/Projects/GRANNY_SMITH/Builds/MacOSX/build/Debug/GRANNY_SMITH.vst3: resource fork, Finder information, or similar detritus not allowed I tried running the same command in my terminal (replaced --verbose=4 with -vvvvv as suggested), and it gave me the same resource fork error. I then tried your test case with a MyTrue.app situation, and confirmed that com.apple.FinderInfo was causing the error. In the dummy app, I was able to remove the attribute added by SetFile and then the codesign worked fine. However, the attribute in my actual file that's stopping my build still refuses to be removed by any means. One thing I noticed: in the dummy app, the attribute that appeared was 'com.apple.FinderInfo: TEXT', while the attribute showing up in my

Yes, We have included the com.apple.security.device.usb entitlement and following are the details- Checking with codesign is only half of the validation process. Take a look at this forum post for a detailed walkthrough followed by an example of the output. Would it help if we share our dmg as well? Can you please share your email or any other way to send that? Assuming the validation shows the entitlement is properly applied, then please file a bug on this. As part of that bug, do the following: Note the details of the hardware you're working with. If possible, upload a copy of the build that's failing. Collect an IORegistryExplorer.app snapshot and upload it to the bug. Reproduce the issue you're seeing multiple times, noting exactly what times you'd triggered the issue in each test. Collect a sysdiagnose and upload it to the bug. ...then post the bug number back here. Once the bug is filed and the data uploaded, I can pull the data from there and see what I can determine. __ Kevin Elliott DTS Engi

There’s two parts to this: Why can’t you remove the Finder info attribute? Why are you trying to remove the Finder info attribute? IMO the second part is the interesting one. Apropos that you wrote: [quote='774781021, jsflack, /thread/774781, /profile/jsflack'] I came to this problem because my Xcode project was failing to build due to the error resource fork, Finder information, or similar detritus not allowed [/quote] Blinding remove all extended attributes in the hope that’ll fix this problem is not a great idea. Rather, you should track down how the extended attributes got there in the first place [1], and remove them at the source. If you look at the build transcript (see Command [something] failed with a nonzero exit code), what is the exact output from codesign? If you repeat that command from Terminal, do you get the same output? Usually that’s the case, but it’s always good to confirm. If you, so can start running experiments to work out exactly what it’s complaining about. One option is to

Both. The previous codesign output was for the containing app and this is for the extension: com.apple.security.app-sandboxcom.apple.security.files.user-selected.read-onlycom.apple.security.get-task-allow

Hi Kevin, Yes, We have included the com.apple.security.device.usb entitlement and following are the details- codesign -d --entitlements :- Refresh Pro.app/Contents/Library/LaunchServices/com.prograde.pgdrefreshpro.helpertool Executable=/Applications/Refresh Pro.app/Contents/Library/LaunchServices/com.prograde.pgdrefreshpro.helpertool warning: Specifying ':' in the path is deprecated and will not work in a future release com.apple.security.cs.allow-dyld-environment-variablescom.apple.security.cs.allow-jitcom.apple.security.cs.allow-unsigned-executable-memorycom.apple.security.cs.disable-library-validationcom.apple.security.device.usb``` codesign -d --entitlements :- Refresh Pro.app/ Executable=/Applications/Refresh Pro.app/Contents/MacOS/Refresh Pro warning: Specifying ':' in the path is deprecated and will not work in a future release com.apple.security.cs.allow-dyld-environment-variablescom.apple.security.cs.allow-jitcom.apple.security.cs.allow-unsigned-executable-memorycom.apple.security.c

I have set trust back to system defaults and I have the DeveloperIDG2CA intermediate installed and im still unable to sign MyTrue. I was trying to follow your troubleshooting page but I fail at the first obstacle unlocking keychain and trying to sign Mytrue still results in a error % security unlock-keychain password to unlock default: % codesign --force --timestamp --sign my hash MyTrue MyTrue: replacing existing signature Warning: unable to build chain to self-signed root for signer Developer ID Application: ,,,,,,, MyTrue: errSecInternalComponent im very aware im probably doing something wrong I am at a loss. Thank you for your reply

It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits. Moreover xctest was able to present local network access dialogue when also run from Xcode it seems. Xcode’s testing infrastructure is interesting because it runs with or without a host application. With a host application, the test inherits the privileges of that app. Without a host application things get weird. So it can be said Im just experimenting Right, cool. That matters because it affects what workarounds you have access to. I tried some things here in my office and the results were… well… interesting: An Xcode project created from the macOS > Command Line Tool template just works. A Swift package created from the macOS > Command-Line Tool template prompts, but then fails to get access. In both cases you can get things to work by choosing Product > Scheme > Edit Scheme and then selecting Options > Console > Terminal. This runs the tool in Terminal, so it inheri