codesign

Thank you. I did a little more digging after writing this post yesterday, and better understand the difference now between certificate categories (distribution/development). So the complexity with the developer build process is it seems like xcode manages all of this and is the easy way to do things. However, our project is primarily Go with some embedded objective-c. In other projects within our org, we have sort of a standard way of setting things up (using makefiles). For example, to get a development environment up for a specific project, we just clone and run make dev for consistency and sanity. I'm not ultra familiar with xcode, so I'm not sure if it's worth the hassle to have it run the go build, and i'm unsure of whether we can use CI if we do. Somewhat related follow-up question: Is there a way to avoid touching the private key for the precious developer certs (i.e., have a hardware security module / HSM generate and store the key and use an audited service? We use code signing certificates internall

[quote='774923021, chipcastle, /thread/774923, /profile/chipcastle'] Is the .app directory and file structure/naming sufficient? [/quote] It looks reasonable enough. A good place to start with this stuff is Placing Content in a Bundle. If you need more info then create a test project in Xcode, build it, and see what it did. [quote='774923021, chipcastle, /thread/774923, /profile/chipcastle'] how do I lint this file … ? [/quote] You can lint it with plutil. Indeed, I recommend you do that. Actually, my general advice is that you use plutil to convert it to the XML format, which means it’s not just technically correct but in the canonical format. [quote='774923021, chipcastle, /thread/774923, /profile/chipcastle'] and determine if it contains all of the necessary key/value pairs? [/quote] It’s hard to answer that, because it depends what you app does. However, a good place to start is with the above-mentioned Xcode project. [quote='774923021, chipcastle, /thread/774923, /profile/chipcastle'] is codesigning

[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