Closed directionless closed 2 years ago
this may have an impact on any osquery related autopkg recipes that do signing checks. But those can be easily updated so I don't see that being a blocker.
This change may impact those who do Privacy Preferences Policy Control(PPPC) whitelisting of osquery based on upon code-signer for full disk access I am also unsure on how some management systems also depending on individual setup this may also cause some further issues.
However I would not consider this a blocker and should just be communicated.
Slack had a request to communicate it via the release notes.
Request for the issues certificate subject ID as this is used in PPPC profiles as such where the current one is B89LNTUADM
<dict>
<key>Allowed</key>
<true/>
<key>CodeRequirement</key>
<string>identifier osqueryd and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = B89LNTUADM</string>
<key>Comment</key>
<string></string>
<key>Identifier</key>
<string>/usr/local/launcher/bin/osqueryd</string>
<key>IdentifierType</key>
<string>path</string>
</dict>
And a request to PR against https://github.com/autopkg/weswhet-recipes/blob/master/Kolide-Launcher/launcher.download.recipe#L71-L74
Signing keys are done. I filed issues against many things over in autopkg
For the last many years, osquery has been signed by a Facebook's apple account. As the osquery foundation now has it's own apple account, we will soon transitioning to using osquery's account to sign.
It is unclear whether this will have adverse impact on any in the macadmins community. This ticket is meant as a place to solicit feedback. Especially if someone anticipates this as a problem, or has a suggestion.
B89LNTUADM
3522FA9PXF