Update the audit to prefer ftpmirror.gnu.org over ftp.gnu.org as
suggested by GNU [1]:
> We recommend using this generic ftpmirror.gnu.org address wherever
> possible in links, documentation, etc., to reduce load on the main GNU
> server.
The audit is temporarily disabled to allow migrating all homebrew/core
formulae first.
Should help to address #20456.
[1]: https://www.gnu.org/server/mirror.en.html
- Since `head` must now specify a url and branch, the `head do` block
with only these stanzas can be condensed to the single-line
`head "url", branch: "branch"` format.
- I found a few occurrences of this pattern from
https://github.com/orgs/Homebrew/projects/5?pane=issue&itemId=97021840,
that is an automated style request for:
`core: use / instead of + operator in e.g. (lib+"lv").install "lv.hlp"`.
- Upon adding tests I realised that there's also the `prefix + "bin"`
case that's already handled differently, so let's combine the handling
given it's the same `+` that's wrong.
Add a new RuboCop to detect the use of 0.0.0.0 in formulae which
indicates binding to all network interfaces, internally or externally,
so is a bad default and potentially a security risk.
Co-authored-by: Issy Long <me@issylong.com>
Inspired by curl's blog post, [Detecting malicious Unicode][1], this likely captures most if not all cases and nudges the user toward supplying IDNs with punycode.
A possible improvement would be telling the user exactly what punycode domain to use instead, but that may require another library as I can't quickly find something built into the Ruby stdlib that handles punycode encoding.
[1]: https://daniel.haxx.se/blog/2025/05/16/detecting-malicious-unicode/
Co-authored-by: Štefan Baebler <319826+stefanb@users.noreply.github.com>
Before this change, `brew bottle` would add the `:arm64_linux` bottle
lines last. This would make `brew style` complain because it wants the
`arm64_*` bottles listed first.
Let's fix this by retaining the existing style as closely as possible:
- macOS bottles are listed first
- for each OS, arm64 bottles are listed first (just as we do on macOS)
In particular, `brew bottle` will now insert `:arm64_linux` bottle lines
just above the `:x86_64_linux` bottle lines (but still below the macOS
bottle lines).
x86_64 may continue to be a more popular platform on Linux for quite
some time. However, users looking for those bottles can continue to look
in the same place as before this change (i.e., the last line of the
bottle block). Taking this together with the consistency on macOS
mentioned above, I think this is the right way forward here.
For concreteness, here are some examples of bottle blocks before and after
this change.
Before this change, immediately after `brew bottle`:
bottle do
sha256 arm64_sequoia: "1a57e04052f4bae4172d546a7927c645fc29d2ef5fafbec19d08ee1dddc542fb"
sha256 arm64_sonoma: "a58cf9af5d04d3d5709b5337f3793586087a79e178da51d1f3978c0c13b8cf34"
sha256 ventura: "6d8b90b2cbb31dcb78394c6540f5454cd57232fc309921173814f880e63718f0"
sha256 x86_64_linux: "cd5faac2834ba79e39429b9aac99e4f69d6e6023cbb1cbcd0b62e94cfc69bb2a"
sha256 arm64_linux: "457d3e9bd0c287483e27f29a488a18c90e1f55be076fc49b07942ef396c419be"
end
Before this change, after doing `brew style --fix`:
bottle do
sha256 arm64_sequoia: "1a57e04052f4bae4172d546a7927c645fc29d2ef5fafbec19d08ee1dddc542fb"
sha256 arm64_sonoma: "a58cf9af5d04d3d5709b5337f3793586087a79e178da51d1f3978c0c13b8cf34"
sha256 arm64_linux: "457d3e9bd0c287483e27f29a488a18c90e1f55be076fc49b07942ef396c419be"
sha256 ventura: "6d8b90b2cbb31dcb78394c6540f5454cd57232fc309921173814f880e63718f0"
sha256 x86_64_linux: "cd5faac2834ba79e39429b9aac99e4f69d6e6023cbb1cbcd0b62e94cfc69bb2a"
end
After this change:
bottle do
sha256 arm64_sequoia: "1a57e04052f4bae4172d546a7927c645fc29d2ef5fafbec19d08ee1dddc542fb"
sha256 arm64_sonoma: "a58cf9af5d04d3d5709b5337f3793586087a79e178da51d1f3978c0c13b8cf34"
sha256 ventura: "6d8b90b2cbb31dcb78394c6540f5454cd57232fc309921173814f880e63718f0"
sha256 arm64_linux: "457d3e9bd0c287483e27f29a488a18c90e1f55be076fc49b07942ef396c419be"
sha256 x86_64_linux: "cd5faac2834ba79e39429b9aac99e4f69d6e6023cbb1cbcd0b62e94cfc69bb2a"
end
- I considered writing a cop for this, but it's not worth it:
there are no `[:test, :build]` occurrences in Core and this
Rust rule only applies in Core formulae.
- Some of these I bumped to `typed: strict`, some of them I added
intermediary type signatures to some of the methods to make my life
easier in the (near, hopefully) future.
- Turns out that RuboCop node matchers that end in `?`
can return `nil` if they don't match anything, not `false`.
- These can be either BlockNode, SendNode or AsgnNode,
which are all a type of Node.
- This causes errors in other places because we call
BlockNode or SendNode methods on a Node now. Still TODO.
