The rationale is that a checksum mismatch is a huge security issue.
This means that the current source file, but maybe the initial one,
might have been compromised.
In the case upstream does not respond quickly to clarify what happened,
or fails to respond, we can now rev-bump the formula, disable and unbottle it,
making sure we stop delivering the potentially malicious code
Further improvements:
- Add the url of the project in the error message to redirect users to
the closed pull request where we disabled this, to centralize the discussion
and avoid the opening of multiple new issues
- Add a warning on brew-update that something is fishy upstream
The linkage check currently does nothing to check the validity of
variable-referenced libraries (prefixed with an `@`).
We could rectify that by mimicking the dynamic linker in looking up the
variable-referenced library, but this could get quite complicated.
Instead, let's let the linker do the hard work by checking if we can
`dlopen` libraries and bundles that contain variable linkage. The
`dlopen` will fail if the linker cannot resolve the variable reference.
There are at least two disadvantages to this approach relative to the
alternative suggested above:
1. This doesn't work for binary executables.
2. This doesn't identify which variable references are broken.
It's still better than not checking them at all, which is what we do
currently, and saves us from having to carry around code that parses and
verifies variable references directly.
Whenever the `sysctl` call does not match `"Apple"*`, we can be sure
that `HOMEBREW_PROCESSOR` is `Intel`, so there's no need for this
additional check.
The previous commit only prevented the installation of an Intel Portable
Ruby into `/opt/homebrew` prefix. Let's actually install an ARM64
Portable Ruby there too.
Since `HOMEBREW_PROCESSOR` is populated using `uname -m`, this will
register as `Intel` even when a native ARM install is running under
Rosetta.
Let's work around this by checking `sysctl -n machdep.cpu.brand_string`.
On my Intel machine:
❯ sysctl -n machdep.cpu.brand_string
Intel(R) Core(TM) i3-1000NG4 CPU @ 1.10GHz
On Apple Silicon:
brew@HMBRW-A-001-M1-001 ~ % sysctl -n machdep.cpu.brand_string
Apple M1
The case of a Rosetta installation of Homebrew is already handled below
the proposed change.
FixesHomebrew/discussions#2434.
One of the more curious bugs, if you use
-Wl,-headerpad_max_install_names on linux, it tries to link a library
named "eaderpath_max_install_names" in, which causes all kinds of weird
havoc.
Most notably, gtester inside glib fails to run for bizarre reasons.
-Wl,-headerpad_max_install_names is not an option anywhere outside macos
anyway, so move it to macos only and avoid the heartache of extremely
weild bugs.
