-
-
Notifications
You must be signed in to change notification settings - Fork 10.8k
audit_min_os: respect arch for universal apps #21110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
audit_min_os: respect arch for universal apps #21110
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR modifies the cask_bundle_min_os method to respect the current architecture when determining minimum macOS version requirements from universal app binaries. Previously, the method returned the highest version requirement across all architectures, which could be incorrect for Intel when the ARM requirement was higher.
Key Changes:
- Architecture-specific requirement collection for universal (fat) binaries
- Returns minimum OS requirement based on the current/simulated architecture instead of the global maximum
- Preserves existing behavior for single-architecture (MachO) binaries
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
3b59f8c to
8ceffdb
Compare
p-linnane
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent nerd snipe!
The `min_os` cask audit uses the `cask_bundle_min_os` method to identify minimum OS requirements from an app bundle but this doesn't always produce the expected output for universal apps. If an app doesn't specify a minimum system version in the `Info.plist` file, the method checks binaries for requirements but it picks the highest version regardless of architecture and that can be inaccurate. For example, if a universal app without a minimum system version in the `Info.plist` has a binary with a macOS requirement of 10.13 or later for Intel and 11 or later for ARM, `cask_bundle_min_os` will incorrectly return 11 as the minimum OS version on Intel. If the cask doesn't have a `depends_on macos:` value, the audit will error with "Artifact defined :big_sur as the minimum macOS version but the cask declared no minimum macOS version". However, this error only applies to ARM, as Intel can rely on the implicit macOS requirement (currently `>= :catalina`). Adding a top-level `depends_on macos: ">= :big_sur"` value resolves the error but it's technically incorrect for Intel. We can accurately address this in casks with separate ARM/Intel apps by calling `depends_on macos:` in an `on_arm` block, though we also have to make the implicit macOS requirement explicit in an `on_intel` block to pass `brew style` (as it won't allow `depends_on` to only be called in one on_arch block). However, that approach doesn't work for a universal app like the previous example, as `cask_bundle_min_os` incorrectly returns the [higher] ARM requirement on Intel. This addresses the issue by modifying `cask_bundle_min_os` to respect the current architecture (i.e., the hardware arch or the arch we're simulating) when identifying OS requirements from binaries. The existing approach lumped all the requirements together and returned the highest version, so this does the same thing for a given arch. This can return an incorrect requirement if the binary covers more than one ARM/Intel arch and the requirements differ but I didn't want to unnecessarily complicate this when we currently only distinguish between general arch types like ARM or Intel. If this ambiguity becomes a problem in the future, we can always modify this setup again.
8ceffdb to
6c3c5f9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
MikeMcQuaid
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense, thanks!
brew lgtm(style, typechecking and tests) with your changes locally?The
min_oscask audit uses thecask_bundle_min_osmethod to identify minimum OS requirements from an app bundle but this doesn't always produce the expected output for universal apps. If an app doesn't specify a minimum system version in theInfo.plistfile, the method checks binaries for requirements but it picks the highest version regardless of architecture and that can be inaccurate.For example, if a universal app without a minimum system version in the
Info.plisthas a binary with a macOS requirement of 10.13 or later for Intel and 11 or later for ARM,cask_bundle_min_oswill incorrectly return 11 as the minimum OS version on Intel. If the cask doesn't have adepends_on macos:value, the audit will error with "Artifact defined :big_sur as the minimum macOS version but the cask declared no minimum macOS version". However, this error only applies to ARM, as Intel can rely on the implicit macOS requirement (currently>= :catalina). Adding a top-leveldepends_on macos: ">= :big_sur"value resolves the error but it's technically incorrect for Intel.We can accurately address this in casks with separate ARM/Intel apps by calling
depends_on macos:in anon_armblock, though we also have to make the implicit macOS requirement explicit in anon_intelblock to passbrew style(as it won't allowdepends_onto only be called in one on_arch block). However, that approach doesn't work for a universal app like the previous example, ascask_bundle_min_osincorrectly returns the [higher] ARM requirement on Intel.This addresses the issue by modifying
cask_bundle_min_osto respect the current architecture (i.e., the hardware arch or the arch we're simulating) when identifying OS requirements from binaries. The existing approach lumped all the requirements together and returned the highest version, so this does the same thing for a given arch. This can return an incorrect requirement if the binary covers more than one ARM/Intel arch and the requirements differ but I didn't want to unnecessarily complicate this when we currently only distinguish between general arch types like ARM or Intel. If this ambiguity becomes a problem in the future, we can always modify this setup again.