“codesign”

[quote='826188022, aehlke, /thread/758358?answerId=826188022#826188022, /profile/aehlke'] looks like this behavior has changed in the last day or two for macOS? [/quote] Yes! It makes me very happy to say that there’s been a significant improvement in this space. It’s now possible to create a macOS provisioning profile that authorises the use of an iOS-style app group. I’ve made a quick update to App Groups: macOS vs iOS: Fight! just now, but at some point I’ll go back to that post and update it properly with all the details. I tested this today with Xcode 15.4b1 running on macOS 15.3.1. Here’s a regular macOS app [1], created from the macOS > App template, using automatic signing, signed for development with an iOS style app group: % codesign -d -vvv Test721701.app … Authority=Apple Development: Quinn Quinn (7XFU7D52S4) … % codesign -d --ent - Test721701.app … [Dict] … [Key] com.apple.security.application-groups [Value] [Array] [String] group.eskimo1.test … % security cms -D -i Test72170

I was able to solve the self-update problem with Quinn's advice regarding codesigning with designated requirements. AssociatedBundleIdentifiers still doesn't work as documented, so I have opened a feedback ticket: FB16563823. Thanks for the help Quinn!

We were missing a step where we were not embedding the provisioning profile in our app, so we created one with default entitlements using our developer account and downloaded that. Then we provided this provisioning profile and the entitlements to the electron build process which embedded the provisioning profile in our app. We also checked the provisioning profile with the commands provided in the link. The app you uploaded to the bug is properly signed. The output of: codesign -dvvv --ent :- Lists these entitlements: com.apple.security.cs.allow-dyld-environment-variables com.apple.security.cs.allow-jit com.apple.security.cs.allow-unsigned-executable-memory com.apple.security.cs.disable-library-validation com.apple.security.device.usb While the output of: security cms -D -i /Contents/embedded.provisionprofile Is this: Entitlements com.apple.application-identifier __TEAM ID__.__BUNDLE ID___ keychain-access-groups __TEAM ID__.* com.apple.developer.team-identifier __TEAM ID__ Once again, please ta

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