I Have 188 Packages, Brew Refuses to Read Two of Them
My intention was modest: free up some disk space. I typed
brew list --formula | wc -l and got 188. Add five application bundles (casks)
to that. Then I asked "how
many of these did I actually ask for?" and the whole thing turned on me. My
package manager answers that question with three different commands, and they
give three different numbers — and in the gap between those answers sit two
packages that appear in no list at all.
The space-clearing job never finished. What came out instead was a measurement
of how much a machine remembers about its own past. I'll walk
through all of it, because every number here has a mechanism underneath it,
and the mechanisms turned out to be more talkative than I expected.
Three commands, three answers
brew list --formula counts the 188 packages on disk. brew leaves says 51:
"the ones that aren't a dependency of another installed formula or cask."
`brew autoremove
--dry-run` says nothing at all: the output is completely empty, there is
nothing safe to remove. One question, three numbers: 188, 51, 0.
They aren't actually asking the same question, and that's what I had failed to
read properly. brew list enumerates directories in the Cellar: what is on
disk. brew leaves collects the runtime-dependency names from the receipts of
installed packages and prints the ones that don't appear in that set: the
leaves of the graph. autoremove asks a third question: which package is both
a leaf and carries the "I didn't ask for this" record.
Putting the four numbers side by side, I finally saw what I had been asking:
| Command | Answer | What it really asks |
|---|---|---|
| brew list --formula | 188 | How many directories are in the Cellar? |
| installed_on_request: true in receipts | 64 | How many installs did I request? |
| brew leaves | 51 | How many are leaves in the graph of loadable formulae? |
| brew autoremove --dry-run | 0 | How many are considered safe to delete? |
The Cellar totals 8.76 GiB. The 64 packages I asked for hold 5.77 GiB of that;
the 124 that came along hold 2.99 GiB. I assumed the single largest item on my
disk was mine: llvm really is (1,797 MiB), but right behind it comes
llvm@21 (1,561 MiB), which I never asked for. zig and lld@21 pulled it
in. The receipts say the same thing: llvm's record carries the request flag,
llvm@21's does not. One of the two largest items on my disk is a decision of
mine; the other is a side effect.
"Why are you here?" has exactly one bit of answer
Every package carries an INSTALL_RECEIPT.json in its own directory. All 188
receipts have the installed_on_request key: 64 say true, 124 say false.
So my machine's memory of "you asked for this" is a single boolean per package.
There used to be a second field: installed_as_dependency. It is missing from
85 of my receipts, true in 74, and false in 29. I found the reason in
Homebrew's own code; the comment in tab.rb refers to the field as
"long-removed" and keeps backward compatibility so old receipts still load. So
those 85 receipts were written by a newer brew that no longer records it. One
bit is what's left.
Up to here it's an engineering decision, and a reasonable one. What stopped me
was looking at my own records. My shell history sits at its ceiling: the file
holds 1,225 lines, but 225 of them end in a backslash continuation, so the
record count is exactly 1,000 — my SAVEHIST limit. The only brew line in
there is a brew upgrade; there is no brew install line at all.
[Every new command of mine deletes an old
one](mustafaerbay.com.tr), and somewhere among
those old ones every single install line went away. The only record of my
intent is that bit, kept by the package manager itself.
My first count was wrong, by the way: grep -c brew ~/.zsh_history returned
nothing and I wrote down "zero". The file isn't plain text — file calls it
extended ASCII, so grep treats it as binary and goes quiet. Asked with
grep -a, one line showed up. The same thing happens to me a couple more times
in the rest of this piece.
!Diagram
The thirteen packages between 51 and 64
Only 51 of the 64 packages I requested are leaves. The first 11 of the
remaining 13 are explainable: even though I asked for them, they are now
something else's dependency. 37 packages lean on openssl@3, 20 on libtiff,
12 on glib. If I tried to delete those, half of them would come straight back
down.
The last two taught me a lesson about measurement. The first time I compared
the lists, I found a package that was "in leaves but not in my requested set":
powershell/tap/powershell. No cause for panic, because the cause wasn't real
— brew leaves prints packages by their full name (tap prefix included),
while the Cellar directory is just powershell. The difference between the sets
was in my text formatting, not in the world. In this kind of measurement, the
first finding being an artifact of your own script is a common event; once I
normalised the names, the gap closed.
But two names refused to close: sshpass and supabase. Both are packages I
requested, both say installed_on_request: true in their receipts, and neither
is a dependency of anything, which by definition makes them leaves. `brew
leaves` doesn't count them. It doesn't error. It doesn't warn. They're just
absent.
Two packages on disk that the manager won't read
One command made the reason obvious:
$ brew info sshpass
Error: Refusing to load formula hudochenkov/sshpass/sshpass from untrusted
tap hudochenkov/sshpass.
Run `brew trust --formula hudochenkov/sshpass/sshpass` or
`brew trust hudochenkov/sshpass` to trust it.
Homebrew now refuses to load formulae from third-party taps unless you have
explicitly trusted that tap. The code has a crisp two-line definition: for a
tap to count as implicitly trusted it must be official and come from its
canonical remote (official? && canonical_remote?). Every other tap needs
approval, and approvals live in ~/.homebrew/trust.json. My file is 63 bytes
and holds a single-entry list: powershell/tap/powershell. The file's
modification time is 15 October, 09:05; the pwsh symlink is dated 09:06. So I
granted an approval in the same minute I installed PowerShell.
How that approval is given matters, because there is no spontaneous "do you
trust this?" prompt anywhere in the code: a trust record only comes from a
hand-typed brew trust command or from brew bundle's explicit flag, and
every other path stops at a single error. The full name in the file
(powershell/tap/powershell) says the same thing: I had the tap's identity in
front of me as I typed that line. The gate asked me for the right thing; I'm
the one who reduced it to a formality. A one-second decision, made so as not to
interrupt an install, turned out months later to be the only thing keeping two
packages inside the inventory.
That enforcement entered Homebrew with the Add tap trust enforcement commit
dated 30 May 2026, but the commit message itself says it was opt-in there: the
rule only applied when HOMEBREW_REQUIRE_TAP_TRUST was set. It became the
default through another commit on 8 June, which shipped first in version 6.0.0
(11 June 2026). So the gate has been shut on this machine for four and a half
months; I'm on 7.0.10 today. I installed sshpass on 24 February 2026 and
supabase two days later: both were inside before the gate existed, the gate
was fitted afterwards, and both ended up on the outside of it.
Now the concrete consequence: brew list shows these two packages, because
that command only looks at Cellar directories. brew leaves doesn't, because
it cannot load the formula. brew outdated reports 120 outdated formulae and
neither of them is on that list. Asked by name, it throws the error above. So
the scope of my update scan is not 188 packages, it's 186.
These two aren't dormant files either. The /opt/homebrew/bin/sshpass and
/opt/homebrew/bin/supabase links are in place, both are in my PATH, and both
run. sshpass -V prints version 1.06 and a 2011 copyright line. supabase is
2.75.0; that release went out on 2 February 2026, and the newest one upstream
was published this morning. Eight months sit in between.
The instructive part is this: my package manager didn't tell me, the package
itself did. Run supabase --version and two lines appear under the version
number saying a newer release exists and 2.75.0 is what's installed. The update
information is right there on the machine; the tool whose job is to collect it
and show it to me in one list has dropped that package from its list.
brew leaves being silent is, to me, the actual defect. When it can't load a
formula it drops the package from the list and doesn't tell me; the command's
error stream comes back completely empty. A one-line "I couldn't read these two
packages" would have replaced my hand-rolled set comparison. What the code does
is technically consistent — an unloadable
formula has no place in the graph — but an inventory command should at least
confess that its count is incomplete. If it were mine, I'd print the refusal as
a warning rather than an error: the behaviour stays the same, and the user's
blind spot closes.
I have no objection to the approval mechanism itself, quite the opposite. A
formula is Ruby code that runs during installation; the build steps, the
download addresses, the post-install scripts all come from that file. An
unaudited repository quietly updating that code amounts to permission to
execute code on my computer. I'd put the gate in the same place. My objection
isn't to the gate but to what happens behind it going unrecorded. Refusing to
load a formula I haven't trusted is the right call; dropping it from the
inventory as well erases the difference between "I won't load this" and "this
isn't here". And these two packages don't leave the disk or the PATH, and they
keep running: they just stop being counted.
The security side turns into a pleasant irony here. The gate's purpose is
right: don't blindly run code from a tap I haven't audited. But once the gate
closes, whoever is left inside also falls outside of management. NIST's guide to
enterprise patch management planning puts inventory second among its planning
recommendations (§3.2, Inventory Your Software and Assets) and says
inventories must be constantly updated or they go stale quickly; the same
section notes that a software bill of materials (SBOM) from a vendor can
augment that inventory. Mine is two lines short, and noticing it required
comparing sets by hand.
Why autoremove said zero
I had a bit of paranoia here: I didn't request 124 packages, so some of them
must be orphans. That turned out to be wrong. The graph, assembled from the
runtime-dependency lists in the receipts, shows that every one of the 124
unrequested packages has at least one requester; zero orphans. That's the real
reason autoremove came back empty.
But reading the code showed me there are three separate ways for it to come
back empty. autoremove only deletes packages that pass all three filters:
nothing in the graph depends on them, their receipt says installed_on_request
is explicitly false, and they were poured from a bottle (pre-built).
Packages built from source never even enter the list; three of them are like
that on this machine (powershell, sshpass, supabase). Cask dependencies
are separately protected as well.
On this machine the first of those three filters was enough on its own: with no
orphaned package, the list is empty before the others matter. The other two are
waiting for the day the graph changes: the three source-built packages on this
machine will never enter autoremove's list even if their requesters
disappear. For
someone who
actually wants to free space, the useful information is elsewhere: which of my
requests is single-handedly holding how many packages? My poppler install
holds 18 packages on its own, ffmpeg and ghostscript six each. Requesting
composer brings 56 packages into the closure, php 55, poppler 51. A
single brew uninstall decision frees 18 packages by that count — and none at
all by autoremove's answer today.
There are leftovers, too: brew cleanup --dry-run says roughly 41.9 MB. Four
packages have more than one version sitting in the Cellar; ca-certificates
has three at once (versions dated 19 March, 13 August and 25 September 2026).
Against 8.76 GiB, 41.9 MB is a comic number for my disk-space goal, but at
least nobody is hiding that number from me. After the measurement where I
deleted apps and [left 661 MiB of data
behind](mustafaerbay.com.tr), I pay
more attention to where the residue hides than to how big it is.
How far I can trust the receipt
With the measurement done, I was going to look at the dates in the receipts and
draw an "age distribution of my packages" chart. Luckily I tripped over an odd
line first: git-filter-repo appears to have been installed on 20 October 2026,
yet the same receipt's homebrew_version field says 4.6.9-6-g24e7d8f. That
tag is dated 3 September 2025, thirteen months before the install. Of the 70
packages installed after 24 June 2026, 24 carry a receipt naming a brew version
older than 6.0.
The answer is in the source again. When installing from a bottle, brew doesn't
write the receipt from scratch; it loads the one that came inside the bottle and
then refreshes only specific fields — install time, installed_on_request,
architecture, source path and so on. homebrew_version is not among the
refreshed fields. So the brew version in a receipt is the version of the brew
that built that bottle, not the one that installed it. The chart I was
planning to draw would have shown the history of Homebrew's build servers, not
of my machine.
The install time (time) field isn't an intent date either: since every
upgrade rewrites the receipt, that field holds "the moment this version was
installed". My oldest receipt is 21 January 2025 (git), the newest 20 October
2026. Between those two dates, "when did I first ask for this package?" is
written down nowhere. The intent bit surviving an upgrade is not an accident but
deliberate: the code reads the value from the existing receipt and carries it
into the new one. The only thing carried over is that bit — not the date.
Running the same measurement on your own machine
None of the numbers above needs a special tool; they all come from reading the
receipts in the Cellar. This single line gives you the request/dependency
split:
for r in /opt/homebrew/Cellar/*/*/INSTALL_RECEIPT.json; do
/usr/bin/python3 -c 'import json,sys; j=json.load(open(sys.argv[1])); \
print(j.get("installed_on_request"))' "$r"
done | sort | uniq -c
On my machine this prints 128 False and 65 True; that totals 193, not 188.
The difference comes from four packages that keep more than one version in the
Cellar: the command counts every version directory, while my table takes the
newest receipt per package (64/124). If you're going to compare your number
with somebody else's, make sure both are counting the same thing.
To find the invisible ones, comparing two lists is enough, but do not forget to
strip the tap prefixes, or you'll see the same ghost difference I saw on my
first pass:
comm -23 \
<(ls /opt/homebrew/Cellar | sort) \
<(brew leaves | sed 's|.*/||' | sort)
For me this command dumps 137 names (188 minus 51), and every one of them means
"on disk, not in the leaf list". Most are legitimate, in that they're somebody's
dependency; brew info <name> tells you in one line which ones can't be read.
The paths differ by architecture: /opt/homebrew on Apple Silicon,
/usr/local on Intel Macs.
There is, however, a far shorter way to do this whole comparison, and I took
the long road until I found it. First, a single flag:
brew list --formula --full-name | grep /
That prints every package coming from a third-party tap by its full name — for
me, exactly three lines: the list of candidates for becoming invisible. Second,
open the gate for the length of one command and measure the difference:
HOMEBREW_NO_REQUIRE_TAP_TRUST=1 brew leaves | wc -l # 53 for me, normally 51
HOMEBREW_NO_REQUIRE_TAP_TRUST=1 brew outdated --formula # 121 for me, normally 120
The difference is exactly the two packages I expected, and the only one added
to the update list is supabase: so of the two that fall out of scope, one
really is behind, and the other (sshpass 1.06) is the newest version in its
own tap. Homebrew marks this variable as one that will be removed in a later
release, so it isn't a permanent fix; but for a once-a-year inventory audit
it's exactly what I was looking for. Your numbers will obviously come out
different; the value of the measurement isn't in the number, it's in how far
the four answers drift apart.
What I'll do tonight
At the end of the measurement my to-do list got shorter but clearer:
- Settle the two invisible packages. Do I need sshpass? The cost of
keeping a binary with a 2011 copyright in my PATH is higher than either
making it visible with brew trust or removing it. Before deciding, I'll
scan the scripts I use.
- Move supabase to where the manager can see it. There's no defensible
reason to keep a CLI that's eight months behind outside the patch scan.
- Keep my intent somewhere other than brew. A 64-line Brewfile is a
better memory than one bit per package; my shell history clearly doesn't
remember.
- Read the tap inventory once a year. I have four taps, three of them
third-party. Adding a line to the trust file took me a second; reading it
takes a second too.
There's no new tool on that list, because the missing piece was never a tool.
My package manager answers three questions from three different places, and I
had been treating all three as the same question.
The number that stays with me isn't 188 or 0; it's 2. When a security gate goes
up, we usually think "that thing can't get in anymore". But the gate can also
make invisible what is already inside: the same mechanism both protects and
drops things out of the catalogue. The inventory our machines report to us is
not an inventory of what they measure, but of what they can read.
Official Sources
- Homebrew — the tap trust enforcement commit
- Homebrew — Library/Homebrew/trust.rb
- Homebrew — the brew leaves implementation
- Homebrew — the autoremove filters
- Homebrew — the install receipt (tab.rb)
- Homebrew — tap definition and implicitly_trusted? (tap.rb)
- NIST SP 800-40r4 — Guide to Enterprise Patch Management Planning
- CISA — Software Bill of Materials
2 reactions
Mentions
Security takeaways from the Binance hack, send this to your devs: Never download or install apps/packages on MacOS without triple-checking the source first. Install homebrew from the developer's official page (Homebrew/install) not from Google. Job Interviews (one of the most common ways to hack lately): 1. Never do a job interview on your work laptop (obvious reasons) 2. Don't download software for the meeting (didn't happen here, but worth a mention) 3. If you have to clone a code repository and run its build/tests/scripts - it MUST be in a sandbox environment, never your machine Simple, stupid, boring security practices, that can save billions when followed. Stay safe🙏
Restart MongoDB Commands !MongoDB Logo It’s not entirely clear how to quickly start, stop and restart MongoDB with a command line, so I’ve documented it here based on the need for a simple, straightforward approach. MongoDB Commands Use the following commands to start, stop or restart MongoDB. Mac OS On Mac OS the installation process for MongoDB’s Community Edition uses the Homebrew brew package manager with the help of the official MongoDB tap. Starting, stopping and restarting MongoDB on a Mac involves using brew services. Start brew services start mongodb-community@6.0 Stop brew services stop mongodb-community@6.0 Restart brew services restart mongodb-community@6.0 Ubuntu/Debian MongoDB can be managed on linux machines in two ways: 1. service command 2. systemctl command service is used for running init scripts from the terminal. systemctl is a newer initialization system that aims to replace SysVInit. Most Linux distributions such as Debian and Red Hat are already using SystemD as their init system out of the box, so I’m including both here for reference. Start For systemd: sudo systemctl start mongod Or for service: sudo service mongod start Stop For systemd: sudo systemctl stop mongod Or for service: sudo service mongod stop Restart For systemd: sudo systemctl restart mongod Or for service: sudo service mongod restart Windows I’ve never used MongoDB in a Windows IIS environment, but for reference here’s what MongoDB has documented for starting, stopping and restarting the service. Start In the Windows Services console right-click on the MongoDB service and click Start. Stop In the Windows Services console right-click on the MongoDB service and click Stop. Restart In the Windows Services console right-click on the MongoDB service and click Start/Restart.
It's fixed in homebrew: github.com/Homebrew/homebrew-core/commit/5af25e90…
Homebrew Git updated away from macOS's system cURL
Yes, I realized we have a gap there. I spoke too soon about Git being patched just because our own CA bundle was. My apologies. There's a fix incoming here[1]. [1]: homebrew-core#321878
Edit: Sorry, I forgot that I had patched my local bundle. This might indeed be an oversight, I'm looking at it now. Edit 2: This is being fixed now[1]. Everything below is stale. I couldn't reproduce this: % which git /opt/homebrew/bin/git % git ls-remote https://git-emudhra.we-have-a-problem.com/check.git fatal: unable to access 'https://git-emudhra.we-have-a-problem.com/check.git/': SSL certificate problem: unable to get local issuer certificate Make sure your `git` binary is Homebrew's, not the system/XCode CLT one. If you see `/usr/bin/git`, you're not using the Homebrewed Git. [1]: homebrew-core#321878
AirBuild is now available in Homebrew ❤️ Thx to the community homebrew-cask#296821
I Have 188 Packages, Brew Refuses to Read Two of Them My intention was modest: free up some disk space. I typed brew list --formula | wc -l and got 188. Add five application bundles (casks) to that. Then I asked "how many of these did I actually ask for?" and the whole thing turned on me. My package manager answers that question with three different commands, and they give three different numbers — and in the gap between those answers sit two packages that appear in no list at all. The space-clearing job never finished. What came out instead was a measurement of how much a machine remembers about its own past. I'll walk through all of it, because every number here has a mechanism underneath it, and the mechanisms turned out to be more talkative than I expected. Three commands, three answers brew list --formula counts the 188 packages on disk. brew leaves says 51: "the ones that aren't a dependency of another installed formula or cask." `brew autoremove --dry-run` says nothing at all: the output is completely empty, there is nothing safe to remove. One question, three numbers: 188, 51, 0. They aren't actually asking the same question, and that's what I had failed to read properly. brew list enumerates directories in the Cellar: what is on disk. brew leaves collects the runtime-dependency names from the receipts of installed packages and prints the ones that don't appear in that set: the leaves of the graph. autoremove asks a third question: which package is both a leaf and carries the "I didn't ask for this" record. Putting the four numbers side by side, I finally saw what I had been asking: | Command | Answer | What it really asks | |---|---|---| | brew list --formula | 188 | How many directories are in the Cellar? | | installed_on_request: true in receipts | 64 | How many installs did I request? | | brew leaves | 51 | How many are leaves in the graph of loadable formulae? | | brew autoremove --dry-run | 0 | How many are considered safe to delete? | The Cellar totals 8.76 GiB. The 64 packages I asked for hold 5.77 GiB of that; the 124 that came along hold 2.99 GiB. I assumed the single largest item on my disk was mine: llvm really is (1,797 MiB), but right behind it comes llvm@21 (1,561 MiB), which I never asked for. zig and lld@21 pulled it in. The receipts say the same thing: llvm's record carries the request flag, llvm@21's does not. One of the two largest items on my disk is a decision of mine; the other is a side effect. "Why are you here?" has exactly one bit of answer Every package carries an INSTALL_RECEIPT.json in its own directory. All 188 receipts have the installed_on_request key: 64 say true, 124 say false. So my machine's memory of "you asked for this" is a single boolean per package. There used to be a second field: installed_as_dependency. It is missing from 85 of my receipts, true in 74, and false in 29. I found the reason in Homebrew's own code; the comment in tab.rb refers to the field as "long-removed" and keeps backward compatibility so old receipts still load. So those 85 receipts were written by a newer brew that no longer records it. One bit is what's left. Up to here it's an engineering decision, and a reasonable one. What stopped me was looking at my own records. My shell history sits at its ceiling: the file holds 1,225 lines, but 225 of them end in a backslash continuation, so the record count is exactly 1,000 — my SAVEHIST limit. The only brew line in there is a brew upgrade; there is no brew install line at all. [Every new command of mine deletes an old one](mustafaerbay.com.tr), and somewhere among those old ones every single install line went away. The only record of my intent is that bit, kept by the package manager itself. My first count was wrong, by the way: grep -c brew ~/.zsh_history returned nothing and I wrote down "zero". The file isn't plain text — file calls it extended ASCII, so grep treats it as binary and goes quiet. Asked with grep -a, one line showed up. The same thing happens to me a couple more times in the rest of this piece. !Diagram The thirteen packages between 51 and 64 Only 51 of the 64 packages I requested are leaves. The first 11 of the remaining 13 are explainable: even though I asked for them, they are now something else's dependency. 37 packages lean on openssl@3, 20 on libtiff, 12 on glib. If I tried to delete those, half of them would come straight back down. The last two taught me a lesson about measurement. The first time I compared the lists, I found a package that was "in leaves but not in my requested set": powershell/tap/powershell. No cause for panic, because the cause wasn't real — brew leaves prints packages by their full name (tap prefix included), while the Cellar directory is just powershell. The difference between the sets was in my text formatting, not in the world. In this kind of measurement, the first finding being an artifact of your own script is a common event; once I normalised the names, the gap closed. But two names refused to close: sshpass and supabase. Both are packages I requested, both say installed_on_request: true in their receipts, and neither is a dependency of anything, which by definition makes them leaves. `brew leaves` doesn't count them. It doesn't error. It doesn't warn. They're just absent. Two packages on disk that the manager won't read One command made the reason obvious: $ brew info sshpass Error: Refusing to load formula hudochenkov/sshpass/sshpass from untrusted tap hudochenkov/sshpass. Run `brew trust --formula hudochenkov/sshpass/sshpass` or `brew trust hudochenkov/sshpass` to trust it. Homebrew now refuses to load formulae from third-party taps unless you have explicitly trusted that tap. The code has a crisp two-line definition: for a tap to count as implicitly trusted it must be official and come from its canonical remote (official? && canonical_remote?). Every other tap needs approval, and approvals live in ~/.homebrew/trust.json. My file is 63 bytes and holds a single-entry list: powershell/tap/powershell. The file's modification time is 15 October, 09:05; the pwsh symlink is dated 09:06. So I granted an approval in the same minute I installed PowerShell. How that approval is given matters, because there is no spontaneous "do you trust this?" prompt anywhere in the code: a trust record only comes from a hand-typed brew trust command or from brew bundle's explicit flag, and every other path stops at a single error. The full name in the file (powershell/tap/powershell) says the same thing: I had the tap's identity in front of me as I typed that line. The gate asked me for the right thing; I'm the one who reduced it to a formality. A one-second decision, made so as not to interrupt an install, turned out months later to be the only thing keeping two packages inside the inventory. That enforcement entered Homebrew with the Add tap trust enforcement commit dated 30 May 2026, but the commit message itself says it was opt-in there: the rule only applied when HOMEBREW_REQUIRE_TAP_TRUST was set. It became the default through another commit on 8 June, which shipped first in version 6.0.0 (11 June 2026). So the gate has been shut on this machine for four and a half months; I'm on 7.0.10 today. I installed sshpass on 24 February 2026 and supabase two days later: both were inside before the gate existed, the gate was fitted afterwards, and both ended up on the outside of it. Now the concrete consequence: brew list shows these two packages, because that command only looks at Cellar directories. brew leaves doesn't, because it cannot load the formula. brew outdated reports 120 outdated formulae and neither of them is on that list. Asked by name, it throws the error above. So the scope of my update scan is not 188 packages, it's 186. These two aren't dormant files either. The /opt/homebrew/bin/sshpass and /opt/homebrew/bin/supabase links are in place, both are in my PATH, and both run. sshpass -V prints version 1.06 and a 2011 copyright line. supabase is 2.75.0; that release went out on 2 February 2026, and the newest one upstream was published this morning. Eight months sit in between. The instructive part is this: my package manager didn't tell me, the package itself did. Run supabase --version and two lines appear under the version number saying a newer release exists and 2.75.0 is what's installed. The update information is right there on the machine; the tool whose job is to collect it and show it to me in one list has dropped that package from its list. brew leaves being silent is, to me, the actual defect. When it can't load a formula it drops the package from the list and doesn't tell me; the command's error stream comes back completely empty. A one-line "I couldn't read these two packages" would have replaced my hand-rolled set comparison. What the code does is technically consistent — an unloadable formula has no place in the graph — but an inventory command should at least confess that its count is incomplete. If it were mine, I'd print the refusal as a warning rather than an error: the behaviour stays the same, and the user's blind spot closes. I have no objection to the approval mechanism itself, quite the opposite. A formula is Ruby code that runs during installation; the build steps, the download addresses, the post-install scripts all come from that file. An unaudited repository quietly updating that code amounts to permission to execute code on my computer. I'd put the gate in the same place. My objection isn't to the gate but to what happens behind it going unrecorded. Refusing to load a formula I haven't trusted is the right call; dropping it from the inventory as well erases the difference between "I won't load this" and "this isn't here". And these two packages don't leave the disk or the PATH, and they keep running: they just stop being counted. The security side turns into a pleasant irony here. The gate's purpose is right: don't blindly run code from a tap I haven't audited. But once the gate closes, whoever is left inside also falls outside of management. NIST's guide to enterprise patch management planning puts inventory second among its planning recommendations (§3.2, Inventory Your Software and Assets) and says inventories must be constantly updated or they go stale quickly; the same section notes that a software bill of materials (SBOM) from a vendor can augment that inventory. Mine is two lines short, and noticing it required comparing sets by hand. Why autoremove said zero I had a bit of paranoia here: I didn't request 124 packages, so some of them must be orphans. That turned out to be wrong. The graph, assembled from the runtime-dependency lists in the receipts, shows that every one of the 124 unrequested packages has at least one requester; zero orphans. That's the real reason autoremove came back empty. But reading the code showed me there are three separate ways for it to come back empty. autoremove only deletes packages that pass all three filters: nothing in the graph depends on them, their receipt says installed_on_request is explicitly false, and they were poured from a bottle (pre-built). Packages built from source never even enter the list; three of them are like that on this machine (powershell, sshpass, supabase). Cask dependencies are separately protected as well. On this machine the first of those three filters was enough on its own: with no orphaned package, the list is empty before the others matter. The other two are waiting for the day the graph changes: the three source-built packages on this machine will never enter autoremove's list even if their requesters disappear. For someone who actually wants to free space, the useful information is elsewhere: which of my requests is single-handedly holding how many packages? My poppler install holds 18 packages on its own, ffmpeg and ghostscript six each. Requesting composer brings 56 packages into the closure, php 55, poppler 51. A single brew uninstall decision frees 18 packages by that count — and none at all by autoremove's answer today. There are leftovers, too: brew cleanup --dry-run says roughly 41.9 MB. Four packages have more than one version sitting in the Cellar; ca-certificates has three at once (versions dated 19 March, 13 August and 25 September 2026). Against 8.76 GiB, 41.9 MB is a comic number for my disk-space goal, but at least nobody is hiding that number from me. After the measurement where I deleted apps and [left 661 MiB of data behind](mustafaerbay.com.tr), I pay more attention to where the residue hides than to how big it is. How far I can trust the receipt With the measurement done, I was going to look at the dates in the receipts and draw an "age distribution of my packages" chart. Luckily I tripped over an odd line first: git-filter-repo appears to have been installed on 20 October 2026, yet the same receipt's homebrew_version field says 4.6.9-6-g24e7d8f. That tag is dated 3 September 2025, thirteen months before the install. Of the 70 packages installed after 24 June 2026, 24 carry a receipt naming a brew version older than 6.0. The answer is in the source again. When installing from a bottle, brew doesn't write the receipt from scratch; it loads the one that came inside the bottle and then refreshes only specific fields — install time, installed_on_request, architecture, source path and so on. homebrew_version is not among the refreshed fields. So the brew version in a receipt is the version of the brew that built that bottle, not the one that installed it. The chart I was planning to draw would have shown the history of Homebrew's build servers, not of my machine. The install time (time) field isn't an intent date either: since every upgrade rewrites the receipt, that field holds "the moment this version was installed". My oldest receipt is 21 January 2025 (git), the newest 20 October 2026. Between those two dates, "when did I first ask for this package?" is written down nowhere. The intent bit surviving an upgrade is not an accident but deliberate: the code reads the value from the existing receipt and carries it into the new one. The only thing carried over is that bit — not the date. Running the same measurement on your own machine None of the numbers above needs a special tool; they all come from reading the receipts in the Cellar. This single line gives you the request/dependency split: for r in /opt/homebrew/Cellar/*/*/INSTALL_RECEIPT.json; do /usr/bin/python3 -c 'import json,sys; j=json.load(open(sys.argv[1])); \ print(j.get("installed_on_request"))' "$r" done | sort | uniq -c On my machine this prints 128 False and 65 True; that totals 193, not 188. The difference comes from four packages that keep more than one version in the Cellar: the command counts every version directory, while my table takes the newest receipt per package (64/124). If you're going to compare your number with somebody else's, make sure both are counting the same thing. To find the invisible ones, comparing two lists is enough, but do not forget to strip the tap prefixes, or you'll see the same ghost difference I saw on my first pass: comm -23 \ <(ls /opt/homebrew/Cellar | sort) \ <(brew leaves | sed 's|.*/||' | sort) For me this command dumps 137 names (188 minus 51), and every one of them means "on disk, not in the leaf list". Most are legitimate, in that they're somebody's dependency; brew info <name> tells you in one line which ones can't be read. The paths differ by architecture: /opt/homebrew on Apple Silicon, /usr/local on Intel Macs. There is, however, a far shorter way to do this whole comparison, and I took the long road until I found it. First, a single flag: brew list --formula --full-name | grep / That prints every package coming from a third-party tap by its full name — for me, exactly three lines: the list of candidates for becoming invisible. Second, open the gate for the length of one command and measure the difference: HOMEBREW_NO_REQUIRE_TAP_TRUST=1 brew leaves | wc -l # 53 for me, normally 51 HOMEBREW_NO_REQUIRE_TAP_TRUST=1 brew outdated --formula # 121 for me, normally 120 The difference is exactly the two packages I expected, and the only one added to the update list is supabase: so of the two that fall out of scope, one really is behind, and the other (sshpass 1.06) is the newest version in its own tap. Homebrew marks this variable as one that will be removed in a later release, so it isn't a permanent fix; but for a once-a-year inventory audit it's exactly what I was looking for. Your numbers will obviously come out different; the value of the measurement isn't in the number, it's in how far the four answers drift apart. What I'll do tonight At the end of the measurement my to-do list got shorter but clearer: - Settle the two invisible packages. Do I need sshpass? The cost of keeping a binary with a 2011 copyright in my PATH is higher than either making it visible with brew trust or removing it. Before deciding, I'll scan the scripts I use. - Move supabase to where the manager can see it. There's no defensible reason to keep a CLI that's eight months behind outside the patch scan. - Keep my intent somewhere other than brew. A 64-line Brewfile is a better memory than one bit per package; my shell history clearly doesn't remember. - Read the tap inventory once a year. I have four taps, three of them third-party. Adding a line to the trust file took me a second; reading it takes a second too. There's no new tool on that list, because the missing piece was never a tool. My package manager answers three questions from three different places, and I had been treating all three as the same question. The number that stays with me isn't 188 or 0; it's 2. When a security gate goes up, we usually think "that thing can't get in anymore". But the gate can also make invisible what is already inside: the same mechanism both protects and drops things out of the catalogue. The inventory our machines report to us is not an inventory of what they measure, but of what they can read. Official Sources - Homebrew — the tap trust enforcement commit - Homebrew — Library/Homebrew/trust.rb - Homebrew — the brew leaves implementation - Homebrew — the autoremove filters - Homebrew — the install receipt (tab.rb) - Homebrew — tap definition and implicitly_trusted? (tap.rb) - NIST SP 800-40r4 — Guide to Enterprise Patch Management Planning - CISA — Software Bill of Materials
@gdpishere @madmanweb Im sorry if this an obvious ragebait, but top talent from all of these firms would not do an emergency fix if this was just fear mongering by social media accounts, I assume, unless if you are schizo to think MEITY knows better. blog.cloudflare.com github.com/cloudflare/cloudflared/releases tailscale.com status.teleport.sh docs.docker.com docs.docker.com docs.docker.com support.chainguard.dev blog.google blog.mozilla.org ubuntu.com access.redhat.com bugzilla.redhat.com bugs.debian.org archlinux.org pkgs.alpinelinux.org freebsd.org cgit.freebsd.org github.com/omniosorg/omnios-build/blob/r151058/do… github.com/Homebrew/homebrew-core/blob/d02b8762f4… groups.google.com github.com/nodejs/node/releases/tag/v22.23.4 github.com/nodejs/node/releases/tag/v24.22.1 github.com/nodejs/node/releases/tag/v26.12.1 ops.java discuss.python.org github.com/certifi/python-certifi/releases/tag/20… github.com/pypa/pip/releases/tag/26.2.2 github.com/astral-sh/uv/releases/tag/0.13.4 github.com/prefix-dev/pixi/releases/tag/v0.82.1 github.com/sigstore/sigstore-python/releases/tag/… github.com/rustls/webpki/releases/tag/v%2F0.103.16 github.com/rustls/webpki-roots/releases/tag/v%2F1… blog.rust-lang.org github.com/electron/electron/releases/tag/v44.9.1 ca-bundle#154 hex.pm metacpan.org github.com/jdx/mise/releases/tag/v2026.10.17 curl.se github.com/cloudflare/cfssl_trust/releases/tag/tr…
Homebrew つかって、自分のPCにphpを入れている人がいたら、まだ、マージされてないからね。もう少し時間かかりそう。 homebrew-core#320074 t.co