Use full names for tap migration targets

[p-linnane]

tap_migrations.json targets written as user/tap/name, such as minetest to homebrew/cask/luanti or openshift-client to homebrew/core/openshift-cli, were reduced to the bare name, which Homebrew::Trust.trusted? never accepts, so brew update skipped these migrations and suggested a brew trust command that rejects bare names. This keeps the full name for the trust check and the brew install commands, which also lets third-party cask targets match Tap#cask_tokens; new examples cover a formula moving to a renamed cask and a cask moving to a renamed formula without mocking trust.

---

• 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 brew benchmark results.
• 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.

Claude Code (Opus 5.5) found the bug while reviewing the migration path, reproduced the skipped migration without trust mocks, made the change and tests, checked both new examples fail without the change and ran brew lgtm --online.

---

Summary by CodeRabbit

• Bug Fixes
  • Tap migrations now retain the complete destination name when it includes a tap, helping ensure the correct destination is used.
  • Migrations between deleted formulae and casks now select the appropriate installation behaviour for the destination type.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 5d37cd25-919e-4f25-97cc-8bea3579792e

📥 Commits

Reviewing files that changed from the base of the PR and between f63eb29 and dcffb26.

📒 Files selected for processing: 2

• Library/Homebrew/cmd/update_report/reporter.rb
• Library/Homebrew/test/cmd/update-report_spec.rb

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 6 remain after this review.

📝 Walkthrough

For fully qualified tap migration targets, the code now preserves the full target as new_full_name and derives new_name from its final component. Tests cover formula-to-cask and cask-to-formula migration targets.

Changes: Tap migration target names

Layer / File(s)	Summary
Preserve full migration target names Library/Homebrew/cmd/update_report/reporter.rb, Library/Homebrew/test/cmd/update-report_spec.rb	The migration code stores the complete target in new_full_name and derives new_name from its final component. Tests check that formula-to-cask migration uses --cask and cask-to-formula migration uses --overwrite with the full target name.

Priority: ⬇️ Low

Merge Risk: ⚪ Minimal · up to dcffb

This fixes tap migration targets so that full names are preserved for trust checks and install commands. No merge-blocking risk was found.

Security architecture risk: 🔵 Low · up to dcffb

Full package names now reach trust checks and installation commands consistently. However, newly enabled formula-to-cask migrations can leave the original formula unlinked if replacement installation fails.

Retained concerns

• Low · reliability · inferred: Fully qualified formula-to-cask migrations can now pass target authorization and unlink the installed formula before replacement installation succeeds. The existing sequence ignores command failure and has no method-local relink or rollback, so installation failure or interruption can leave the original formula disabled through the prefix. This sequence predates the PR, but its exposure to fully qualified targets increases.

Security review details

Security Blast Radius

• observed — The migration handler's affected assets include installed formula receipts, prefix links and packages installed through normal brew subprocesses. Formula-to-cask handling also invokes cleanup without a package argument, so that operation is not restricted to the migrating package.

Security Findings and Attack Paths

• inferred — No trust bypass was established in the inspected cross-type migration paths: the corrected qualified destination is authorized before it is passed to installation, and subprocess arguments are supplied separately rather than interpolated into a shell command. This conclusion does not establish safety for unsupplied production migration mappings.

Trust Boundaries and Controls

• observed — An absent destination tap is installed automatically only when that tap is trusted. Cross-type package installation additionally checks destination package trust, and an untrusted destination produces instructions rather than an installation call.

Resilience and Maintainability Implications

• observed — Update uses an update lock, and unlink takes a keg lock. These controls provide serialization within their respective scopes; the migration handler still expresses replacement as separate commands without method-local compensation.

Pre-merge checks: 4

Passed checks: 4 passed

Check name	Status	Explanation
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.
Title check		The title clearly summarises the main change: preserving full names for tap migration targets.
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

[MikeMcQuaid]

Thanks!