cask/upgrade: don't read quarantine metadata when quarantine is unavailable

[aholland]

Cask::Upgrade snapshots each app's quarantine state before swapping in the new version. One of the calls it makes, Quarantine.detect, raises unexpected nil xattr when there is no xattr binary to run, which is the normal state on Linux. Everything the snapshot collects is used only inside the Quarantine.available? branch below it, so the snapshot can carry the same guard.

I introduced this in #23556, which added the Quarantine.detect call without the guard its neighbours in that block already have: user_approved? and user_approved_paths both return early when there is no xattr, and signing_identity is a stub off macOS, so detect is the only one of the four that raises.

Homebrew's own CI cannot catch this. The Homebrew Cask shared context is declared :needs_macos, and shared_context_metadata_behavior is :apply_to_host_groups, so every :cask spec inherits that tag and is skipped on Linux. That is also why the same class of bug in brew audit (#23226, fixed in #23229) surfaced in homebrew-cask's CI rather than here. It is why the test below simulates an unsupported system instead of being tagged :needs_linux, which would skip on every platform.

To reproduce, on Linux or anywhere else with no xattr on the path, with an outdated cask that installs an app:

brew upgrade --cask <token>
Error: <token>: unexpected nil xattr

I have not seen this reported, and I would expect very few people to reach it, since it needs a cask actually installed on Linux. #23226 was the same defect in brew audit, which Linux does reach routinely because homebrew-cask audits every cask on Linux CI. This is the upgrade-path sibling of that bug, so it is worth closing even though the path is quieter.

Details

How was this demonstrated? I have no Linux box to hand, so I reproduced the condition on macOS by making Quarantine.xattr return nil, which is exactly what DevelopmentTools.locate("xattr") returns when the binary is absent. Quarantine.detect then raises, and an otherwise passing upgrade spec fails with the cask left at its old version. The new spec was verified red before the change and green after.

Why guard the whole snapshot rather than the one call? Guarding only detect would fix the crash, but the block as a whole exists to read quarantine metadata and its output is consumed only when quarantine is available, so the condition belongs to the block. It also keeps the next probe added there from reintroducing the same bug.

What does the test assert? That an upgrade completes without Quarantine.detect being called when Quarantine.available? is false. This mirrors the regression test added in #23229 for the audit path.

• Have you followed our Contributing guidelines?
• Have you checked for other open Pull Requests for the same change?
• Have you explained what your changes do? Performance claims (e.g. "this is faster") must include Hyperfine benchmarks.
• Have you explained why you'd like these changes included, not just what they do?
• For bug fixes, have you given step-by-step brew commands to reproduce the bug?
• Have you written new tests (excluding integration tests)? Here's an example.
• Have you successfully run brew lgtm (style, typechecking and tests) locally?

---

• I did not use AI/LLM to create this PR, or I disclosed the tool/model below and reviewed its output; I did not attribute commits to AI and will answer maintainer questions and review comments myself without AI/LLM.

Used Claude Code (Fable 5) to investigate and draft; I directed the investigation, and reviewed the diff and every line of this PR text.

---

[MikeMcQuaid]

Makes sense, thanks again @aholland!