MacOSCryptoSettings: Disable encryption if keychain entitlement is missing

[oskirby]

Description

As noted in the discussion of #9584 we have a need to be a bit smarter in how and when we enable cryposettings on MacOS. Traditionally this was done at compile time by doing a no-op for the getKey() in the dummy builds, but this should really be done by examining the processes' entitlements to know whether the binary can access the encrypted settings. The entitlement that guards this access is the keychain-access-group permission.

Normally, when this entitlement is missing, the user is greeted with a login prompt asking for the user's password before permitting them access to the keychain, which is a minor annoyance for developers. This PR will also make unsigned developer builds fall back to plaintext settings instead of triggering such a prompt.

Reference

JIRA Issue: VPN-5486
Inciting PR: #9584
Discussion: here

Checklist

• My code follows the style guidelines for this project
• I have not added any packages that contain high risk or unknown licenses (GPL, LGPL, MPL, etc. consult with DevOps if in question)
• I have performed a self review of my own code
• I have commented my code PARTICULARLY in hard to understand areas
• I have added thorough tests where needed

[mcleinman]

This looks good, but just thinking about ways an internal advisary could use this - if a build isn't codesigned, will shipit (or another part of the release process) fail?

[oskirby]

This looks good, but just thinking about ways an internal advisary could use this - if a build isn't codesigned, will shipit (or another part of the release process) fail?

To the best of my knowledge, the release process doesn't have any checks to ensure that the uploaded artifacts are signed, but users will be presented with errors when trying to install and run unsigned software. However, all of our release tasks depend on signing tasks, so it shouldn't be possible to ship an unsigned build unless we change our taskcluster jobs.

[mcleinman]

Thanks!