- Gives the security guide a URL that targets `homebrew security`.
- Keeps the old supply chain URL working through `redirect_from`.
- Updates internal links while limiting visible text changes.
- remove the FAQ section explaining how to bypass Gatekeeper for
apps from unidentified developers, plus its screenshots
- remove the `pkg allow_untrusted` Cask DSL docs and mark the
`allow_untrusted` definitions `# odeprecated` as they disable
certificate verification
- remove "untar anywhere" and "multiple installations" install
instructions that push users to a non-default prefix and source
builds, dropping them below Tier 1
- explain recent npm and PyPI supply-side incidents and patterns
- contrast Homebrew's reviewed, checksummed, bottled trust model
- note most protections predate the current supply-chain focus
- document mitigations: sandboxing, environment filtering, cooldowns
- note maintainer vetting, inactivity removal and 2FA requirements
- state Homebrew trusts no third-party non-Homebrew repositories
- note tap migrations never move packages out to third-party taps
- note Homebrew does not defer to upstream against users' interests
- explain ephemeral build runners and building from source
- describe the cask trust model and how it compares to upstream
- note bottles are only supported for core and warn off other paths
- explain prioritising security over backwards compatibility
- note layered infrastructure cross-checks and GitHub security features
- explain why Homebrew needs no blanket or double dependency cooldown
- warn about untrusted third-party taps in the interesting taps doc
- record one-sentence-per-line and aligned-table docs Markdown style
- cross-link the new doc from index, Tap Trust and the FAQ
- Avoid keeping no-op opt-in flags after their behaviour became
the default.
- Document the negative switches and environment variables as the
supported opt-out path.
- Let explicit positive CLI switches override environment opt-outs.
- Add `-y` and `--yes` as ask opt-out aliases.
- Use `--no-ask` in tests that need to opt out.
- Regenerate generated command documentation and completions.
- `brew pin` should cover casks now that upgrades skip both package types.
- Cask pin records keep list, info and upgrade output consistent.
- `auto_updates true` casks need a warning because app updaters bypass Homebrew.
- switch `auto_updates true` upgrades to
`HOMEBREW_UPGRADE_AUTO_UPDATES_CASKS` so users keep the
current behavior until Homebrew 5.2.0
- keep hidden `HOMEBREW_NO_UPGRADE_AUTO_UPDATES_CASKS`
support for developer overrides, reject conflicting env
settings early in `brew upgrade`, and keep
`HOMEBREW_DEVELOPER` boolean parsing consistent
- ignore bad bundle versions such as `0.0` so broken
`Info.plist` metadata does not trigger false upgrades
- skip hidden env vars cleanly when generating manpages so
undocumented entries cannot affect formatting
- `FAQ.md` lacked any explanation of how running a
developer command changes update behavior (hourly
instead of daily, tracking `main` instead of tags)
- `MCP-Server.md` only listed user commands; added
`brew style`, `brew typecheck`, `brew tests` and
`brew audit` for contributor awareness
- move the supported and unsupported guidance into
`docs/Versions.md` so users get one consistent answer when
they want to freeze formula versions
- distinguish the churn-reduction knobs from the
personal-tap workflows, including `brew pin`,
`$HOMEBREW_NO_AUTO_UPDATE`, `brew bundle --no-upgrade`,
`$HOMEBREW_BUNDLE_NO_UPGRADE`,
`$HOMEBREW_NO_INSTALL_UPGRADE`,
`$HOMEBREW_NO_INSTALLED_DEPENDENTS_CHECK`,
`brew version-install`, and `brew extract`
- explain the support boundaries that matter in practice:
missed security updates, custom tap maintenance, and only
filing issues after `brew update` when the problem
reproduces with core formulae
- point the FAQ, tips, bundle, and tap docs at the new
section so the wording stays aligned as these workflows
evolve
- clarify in `Support-Tiers.md` that shared multi-user
Homebrew installs are unsupported because Homebrew is
designed around single-user ownership
- tell users running a Homebrew wrapper to get support from
that wrapper first unless the issue reproduces without it
- align `FAQ.md` and `Homebrew-on-Linux.md` with this policy
and remove the old `linuxbrew` role-account guidance
- Most of these were fine still, apart from:
- FAQ: `hub` is less maintained than `gh`.
- Brew-Maintainer-Guide: link to GitHub docs on commit signing via GPG or SSH.
- Interesting-Taps-and-Forks: remove outdated information about `homebrew/core` being in `Library/Taps`.
- New-Maintainer-Checklist: remove outdated information about the `@members` team.
- At the AGM we formed an ad-hoc documentation working group.
- One of our ideas was that we should have a last reviewed date for
documentation, so that we can periodically implement a review
mechanism (GitHub Actions posts to Slack for a regular documentation
outdatedness check?) to track how old docs are and ensure they're
still relevant.
- This is a first step towards that goal, by adding a `last_review_date`
to the metadata of all docs with a date of earlier than Homebrew's
inception because everything needs reviewing so that we start from a
good base!
New installs don't tap `homebrew/core`, so `brew edit foo` fails with
`Error: Invalid usage: foo doesn't exist on disk.` for any package.
Add an instruction to run `brew tap homebrew/core` first, which fixes
this issue.
Patrick Linnane