codesign

I raise this question again. Earlier you suggested: The easiest way to do this is use Xcode’s import/export feature. Launch Xcode, choose Xcode > Settings, select Accounts, select the account in question, then choose Export Apple ID and Code Signing Assets from the action (…) menu. In Xcode 16 I cannot find any import/export commands to move existing codesign certificates/keys to my second Mac. Probably it will easier to create a NEW individual codesign certificate for EVERY Mac I use?

Ok, I had to get some support from the tebako folks before I could reply. Here's the output of the codesign --verify -vvv PATHmanager.app command you suggested: Extract pkg contents /tmp λ xar -xf ~/code/ruby/PATHmanager.pkg Verify Bill of Materials /tmp λ lsbom com.chipcastle.pathmanager.pkg/Bom . 0 0/0 ./PATHmanager.app 40755 0/0 ./PATHmanager.app/Contents 40755 0/0 ./PATHmanager.app/Contents/Frameworks 40755 0/0 ./PATHmanager.app/Contents/Frameworks/libui.dylib 100644 0/0 925632 3337342204 ./PATHmanager.app/Contents/Info.plist 100644 0/0 1415 1981579098 ./PATHmanager.app/Contents/MacOS 40755 0/0 ./PATHmanager.app/Contents/MacOS/._PATHmanager 100755 0/0 0 0 ./PATHmanager.app/Contents/MacOS/PATHmanager 100755 0/0 30036560 1901427662 ./PATHmanager.app/Contents/PkgInfo 100644 0/0 8 742937289 ./PATHmanager.app/Contents/Resources 40755 0/0 ./PATHmanager.app/Contents/Resources/AppIcon.icns 100644 0/0 56310 2265036908 ./PATHmanager.app/Contents/_CodeSignature 40755 0/0 ./PATHmanager.app/Contents/_CodeSign

Sure. But at some point these things stop being technical questions and instead become a reflection of your policy. I agree/understand regarding the policy. I framed the question oddly, but I was really asking if that policy made sense (i.e., was there some other approach to do what I'm saying or is there anything unforseen that I'd encounter). I've already implemented it though and it seems to work out fine, so we'll stick with it. Yes. That is, in fact, the whole reason for a DR, in that it’s a cryptographically sound way for the code to identify itself, such that the system knows that version N+1 of your app is the ‘same code’ as version N. Ok, that's great. My concern was that what constitutes a DR (as emitted by codesign) could change in the future, and that same code meant the exact code the DR was computed for at the time it was run. This is obviously not the case since it is only reliant on certificate OIDs and such (so I'd assume if the signing certificate changes that would be the only thin

I have found that you can also check whether your app executable contains the aps-environment string. For example: grep -n -a aps-environment Payload/MyApp.app/MyApp It did not contain the string before the fix and it did after. This is probably similar to codesign -d --entitlements :- Payload/MyApp.app

Thank you @benjfromlondon for showing me the way! I had the same issue while building using the Xcode@5 in Azure Pipelines although the project was otherwise configured as it should and as many StackOverflow threads indicated it should. I will add below more information about how I fixed the issue and troubleshooting. The fix The Xcode@5 Azure Pipelines task does not sign the archive by default: # Signing & provisioning #signingOption: 'nosign' # 'nosign' | 'default' | 'manual' | 'auto'. Signing style. Default: nosign. #signingIdentity: # string. Optional. Use when signingOption = manual. Signing identity. So I added the following to my Yaml pipeline: (signingOption, signingIdentity and provisioningProfileName) - task: Xcode@5 displayName: 'Build IPA' inputs: actions: 'clean build' configuration: 'Release' sdk: 'iphoneos' xcWorkspacePath: 'ios/MyApp.xcworkspace' workingDirectory: '$(Build.SourcesDirectory)' scheme: 'MyApp' packageApp: true signingOption: 'manual' signingIdentity: 'iPhone Distribution' pr

I’m not exactly an expert on MDM stuff, but my understanding is that the CodeRequirement property is a requirement. It doesn’t have to be the designated requirement of the code in question. Thus, you can create a profile with this property set to a custom requirement, one that’ll accept a development-signed app built by any of your team members. For more background on this, see TN3127 Inside Code Signing: Requirements. Consider this: % codesign -d -r - Test777163 Executable=/Users/quinn/Library/Developer/Xcode/DerivedData/Test777163-cihuekycmkocddfnmmrztacqdito/Build/Products/Debug/Test777163 designated => identifier Test777163 and anchor apple generic and certificate leaf[subject.CN] = Apple Development: Quinn Quinn (7XFU7D52S4) and certificate 1[field.1.2.840.113635.100.6.2.1] /* exists */ % cat custom.txt identifier Test777163 and anchor apple generic and certificate leaf[subject.OU] = SKMME9E2Y8 and certificate 1[field.1.2.840.113635.100.6.2.1] /* exists */ % codesign -v -vvv -R custo

System Extensions framework is meant to be called from a GUI application. Is that the case here? I see a lot of folks try to use the framework from a command-line tool (or daemon or whatever) that’s pretending to be a GUI app, and that often ends badly. I'm using a gui container app, it's just the default App macos template from xcode with the init for the App class changed to start the system extension. Check that you’re container app has a reasonable structure and that the sysex is embedded within that: Seems almost identical:  tree Applications/dns-proxy-tests.app Applications/dns-proxy-tests.app └── Contents ├── Info.plist ├── Library │ └── SystemExtensions │ └── com.myteam.dns-proxy-tests.ne.systemextension │ └── Contents │ ├── Info.plist │ ├── MacOS │ │ └── com.myteam.dns-proxy-tests.ne │ ├── _CodeSignature │ │ └── CodeResources │ └── embedded.provisionprofile ├── MacOS │ ├── __preview.dylib │ ├── dns-proxy-tests │ └── dns-proxy-tests.debug.dylib ├── PkgInfo ├── Resources ├── _CodeSignature │ └── CodeR