Posts

Post not yet marked as solved
7 Replies
4.1k Views
Hi everyone, I'm struggling to access a certificate stored in keychain when using LaunchDaemons and would appreciate any advise to improve over my current workaround with an agent. I'm maintaining an M1-based Mac Mini with macOS Big Sur 11.4 as a build client for Gitlab CI. The machine makes itself known to the orchestrating Gitlab server through the so-called gitlab-runner process which regularly polls the Giltab server for build job requests. It would then eventually call xcodebuild to generate artifacts and upload them to Gitlab. In order to have this process startup automatically, I've loaded it through a /Library/LaunchDaemons/gitlab-runner.plist file in launchctl. This setup has been working greatly for months, making the build client immediately available after a reboot without the need to log into it. I've now started to deploy codesign tasks to the build client and encountered issues with keychain access to the certificate. I installed the certificate and performed security find-identity -v -p codesigning in the Terminal to validate correct installation. I have ensured that the codesign tasks succeed when performed through Terminal manually. A popup was shown on first try about codesign wanting to access to the local keychain, which I always allowed. Codesign then reported success: signed Mach-O universal. The behavior is different for my LaunchDaemons-based codesign tasks (spawned under the same user). I've tried multiple permutations for sudo launchctl load -w /Library/LaunchDaemons/gitlab-runner.plist: SessionCreate=true, local keychain: FAIL (errSecInternalComponent) SessionCreate=true, System keychain: FAIL (errSecInternalComponent) SessionCreate=false, local keychain: FAIL (error: The specified item could not be found in the keychain.) SessionCreate=false, System keychain: FAIL (errSecInternalComponent) I've then tried a user agent launchctl load -w ~/Library/LaunchAgents/gitlab-runner.plist: SessionCreate=true, local keychain: FAIL (errSecInternalComponent) SessionCreate=false, local keychain: OK (Popup -> Always allow, signed Mach-O universal) So apparently, the last variant works reliably. However, it has the severe downside that I now need to log in the user after a reboot in order to kick off the agent. Is there a way to make this work with /Library/LaunchDaemons, possibly through some plist property? As a test I've tried to "Allow all applications" to access the private key associated with the Certificate but that didn't change anything. Best regards Maik
Posted Last updated
.