Consider using `objc2-security`?

[madsmtm]

security-framework-sys contains a bunch of hand-written bindings to the security framework, and is what security-framework provides a high-level wrapper on top of. objc2-security is an auto-generated alternative, which has a bunch of benefits:

• Better type-safety around enums.
  • E.g. kSecAccessControlOr is wrapped into SecAccessControlCreateFlags.Or, just like the Swift binding, or like security-framework does.
• Bindings are marked with nullability information.
  • Nullable parameters use the rusty Option<&CFString> instead of CFStringRef.
  • Non-null parameters use simply &CFString.
• Automatic memory management.
  • E.g. SecAccessControlCreateWithFlags returns Option<CFRetained<SecAccessControl>>, that is, a smart pointer to SecAccessControl which will ensure that CFRelease is called at the correct time. No more need for knowing when to call Self::wrap_under_create_rule(...) vs. Self::wrap_under_get_rule(...).
• Uses objc2-core-foundation (which is similarly auto-generated, with the same benefits) instead of core-foundation.
  • Small usability improvement: string.as_CFTypeRef() is unnecessary, as CFString derefs to CFType.

This would necessarily be a breaking change, so it'd be nice if the move towards not exposing CFString/CFType/... in security-framework's public API was done in the same release (as I expect objc2-security to have at least a few more major versions before settling on v1.0).

I have a WIP branch over here that can be used to see what some of this would look like.

An alternative could be to merge security-framework's functionality into objc2-security itself, not yet sure which option I prefer.

(Btw, I see that you've marked this as "maintenance status = looking-for-maintainer", I could be interested in helping out).