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 (that I maintain), which has a bunch of benefits:
- Better type-safety around enums.
- 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).
security-framework-syscontains a bunch of hand-written bindings to the security framework, and is whatsecurity-frameworkprovides a high-level wrapper on top of.objc2-securityis an auto-generated alternative (that I maintain), which has a bunch of benefits:kSecAccessControlOris wrapped intoSecAccessControlCreateFlags::Or, just like the Swift binding, or likesecurity-frameworkdoes.Option<&CFString>instead ofCFStringRef.&CFString.SecAccessControlCreateWithFlagsreturnsOption<CFRetained<SecAccessControl>>, that is, a smart pointer toSecAccessControlwhich will ensure thatCFReleaseis called at the correct time. No more need for knowing when to callSelf::wrap_under_create_rule(...)vs.Self::wrap_under_get_rule(...).objc2-core-foundation(which is similarly auto-generated, with the same benefits) instead ofcore-foundation.string.as_CFTypeRef()is unnecessary, asCFStringderefs toCFType.This would necessarily be a breaking change, so it'd be nice if the move towards not exposing
CFString/CFType/... insecurity-framework's public API was done in the same release (as I expectobjc2-securityto 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 intoobjc2-securityitself, 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).