brew audit mandates the use of deprecated macOS LDAP.Framework

[rdmark]

brew doctor output

Your system is ready to brew.

Verification

• My "brew doctor output" above says Your system is ready to brew. and am still able to reproduce my issue.
• I ran brew update twice and am still able to reproduce my issue.
• This issue's title and/or description do not reference a single formula e.g. brew install wget. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.

brew config output

HOMEBREW_VERSION: 4.4.13
ORIGIN: https://github.com/Homebrew/brew
HEAD: 6ea9df68df4868ce12ea7c51c85b57dce514f2e8
Last commit: 7 days ago
Branch: stable
Core tap JSON: 29 Dec 18:48 UTC
Core cask tap JSON: 29 Dec 18:48 UTC
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CASK_OPTS: []
HOMEBREW_MAKE_JOBS: 4
Homebrew Ruby: 3.3.6 => /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/3.3.6/bin/ruby
CPU: quad-core 64-bit kabylake
Clang: 12.0.0 build 1200
Git: 2.24.3 => /Library/Developer/CommandLineTools/usr/bin/git
Curl: 8.7.1 => /usr/bin/curl
macOS: 14.7-x86_64
CLT: 12.0.0.32.2
Xcode: N/A

What were you trying to do (and why)?

I'm working on a formula for netatalk. See Homebrew/homebrew-core#202713

The current homebrew audit rules mandates that you use macOS native LDAP libraries in place of the homebrew openldap formula. However, in practice those libraries consist of "LDAP.Framework" which Apple themselves has flagged as deprecated.

See: https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/OSX_Technology_Overview/SystemFrameworks/SystemFrameworks.html

As a side note, there is a similar situation with Berkeley DB, where brew audit wants you to use the native library instead of berkeley-db. However, what's Apple ships in the OSX SDK is a db.h that is very outdated. It lacks symbols needed for my package. (If needed I can file a separate issue ticket for this.)

What happened (include all command output)?

brew audit --new netatalk

  * Dependency 'berkeley-db' is provided by macOS; please replace 'depends_on' with 'uses_from_macos'.
  * Dependency 'openldap' is provided by macOS; please replace 'depends_on' with 'uses_from_macos'.

What did you expect to happen?

brew audit allows the use of openldap (and berkeley-db) in the macOS formula

Step-by-step reproduction instructions (by running brew commands)

Clone my fork of homebrew-core and check out the netatalk-4-0-8 branch

https://github.com/rdmark/homebrew-core/tree/netatalk-4-0-8

Run `brew audit --new netatalk` on the cloned tap

[Bo98]

These are warnings for new formulae only and not hard errors so if you have a use case for ignoring them then feel free to describe that in the pull request. We can override it with a PR label.

For berkeley-db, the latest version has tight licensing restrictions (AGPL) so the OS version is generally preferred unless it can't (which seems to be the case here). Most packages are able to work with the OS version. Some packages use berkeley-db@5 (Sleepycat license) as a middle ground when AGPL restricts usage.

LDAP is a little more complicated as it's soft deprecated - sometimes it's the case that OpenDirectory.framework is supported or in cases like curl we want to minimise dependencies and maximise compatibility with existing configurations so we're actually just matching what Apple do themselves (they also continue to use LDAP.framework for their curl builds). But you can see that there's several cases where openldap is used, including in popular formulae like php: https://github.com/search?q=repo%3AHomebrew%2Fhomebrew-core+%22depends_on+%5C%22openldap%5C%22%22&type=code

It sounds like you've got good use cases for direct dependencies so feel free to mention it in the PR and it will get sorted, don't worry.

[rdmark]

Very well, then I will continue to work through these exceptions in the PR.

The upstream netatalk project also strongly recommends Berkeley DB v4 or v5 for the same licensing reason, and no testing is done against the later Oracle versions. I'll go ahead and flag the dependency as berkeley-db@5 in my formula.

Thanks for sharing the context on LDAP.Framework. Now I understand why Apple is keeping the deprecated framework around. When it comes to netatalk, we want to avoid linking with Objective-C libraries in general, because netatalk is a forking application, and Apple's Objective-C frameworks are not fully fork safe. In fact, Apple has assertions in place that will kill an application when it attempts to fork. There are workarounds for bypassing these assertions, but it's cleaner to avoid Objective-C libraries altogether.

Again, thanks for taking the time to type up a helpful response!