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>
We were selectively requiring the tap.rb file in a few places for
performance reasons. The main method we were referencing was the
`Tap.cmd_directories` method which uses `Pathname` and the `TAP_DIRECTORY`
constant internally. `Tap.cmd_directories` is mostly used in the `Commands`
module and that is loaded very early on in the program so it made sense
to move that command to that module. To facilitate that I moved the
`TAP_DIRECTORY` constant to the top-level and renamed it to
`HOMEBREW_TAP_DIRECTORY`. It now lies in the tap_constants.rb file.
A nice bonus of this refactor is that it speeds up loading external
commands since the tap.rb file is no longer required by default in
those cases.
- We discovered that the following syntax in the formula `sqlsmith`
should actually be OK because the `\n` is like whitespace.
```ruby
cmd = %W[
#{bin}/sqlsmith
--threads=4
--timeout=10
]
shell_output(cmd)
```
- I got bored doing them manually.
- Also now more people can help with letters of the alphabet using `brew style --only=FormulaAuditStrict/Text --fix homebrew/core`.
- This cop checks for the use of `FileUtils.rm_rf` and suggests using
`FileUtils.rm_r` because we should know if we couldn't delete a
thing for some reason, not just force it.
- Previously this only included the formula name.
- But, for example in tests, we have "#{bin}/ansible-test",
not just "#{bin}/ansible". So handle that too.
- I decided to make the error message better by extracting the
binary name from the interpolation, but I'm not sure it was worth it.
```
$ brew audit --strict ansible
ansible
* line 580, col 29: Use `bin/"ansible-test"` instead of `"#{bin}/ansible-test"`
Error: 1 problem in 1 formula detected.
```
- in `brew.sh` split the `case` into those cases that take a single or
no arguments and those that take multiple arguments or handle
multiple commands. This considerably speeds up the
`brew shellenv bash` case that wasn't being handled here before.
- add `setup-ruby` to the list of commands that can be called quickly
by `brew.sh` without additional setup. This speeds up the
`brew setup-ruby` no-op case by ~10x.
- add a parameter to `setup-ruby` to avoid running Bundler if the
command doesn't need it. This makes many more cases for
`brew setup-ruby` to be no-op cases.
- Remove the (now) unused `HOMEBREW_RUBY3` check in `setup-ruby`.
- Improve argument handling in `command_path.sh` to allow it to be
used as a function in `setup-ruby.sh`.
- Add a new RuboCop to check usage of `install_bundler_gems!` is only
inside `dev-cmd` (or a few other acceptable places).
- Use new `processed_source.file_path` API in `formula_cop.rb`
The existing `LivecheckUrlProvided` RuboCop requires a `url` for all
`livecheck` blocks except those using `skip`, `formula`, or `cask`,
as those only appear in a `livecheck` block with no other DSL methods.
We now have a `throttle` method that can be used alongside other DSL
methods (e.g., `url`, `regex`, `strategy`) or by itself. `brew style`
currently fails when `throttle` is used by itself, so this reworks
the conditions to allow this usage.
When the file isn't world-readable, `brew audit` prints a failure
message including a suggestion to `chmod +r` the file. Unfortunately,
this isn't quite right: with both macOS and coreutils, leaving out the
"who" in a chmod only affects bits which would be set in the umask. So,
if the umask doesn't allow world-readable (which might be why the file
wasn't world-readable in the first place), the suggested chmod command
does nothing.
Change to print `chmod a+r` instead; that does have the intended effect.
No other `chmod` suggestions in this file have the same problem.
