Uninstalling casks from untrusted taps

[SplittyDev]

Output of brew config

HOMEBREW_VERSION: 6.0.0
ORIGIN: https://github.com/Homebrew/brew
HEAD: 3d9e344622974a7f96da927fd0407e08581eb437
Last commit: 6 hours ago
Branch: stable
Core tap JSON: 11 Jun 18:06 UTC
Core cask tap JSON: 11 Jun 18:06 UTC
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_DOWNLOAD_CONCURRENCY: 48
HOMEBREW_FORBID_PACKAGES_FROM_PATHS: set
HOMEBREW_MAKE_JOBS: 24
HOMEBREW_REQUIRE_TAP_TRUST: set
Homebrew Ruby: 4.0.5 => /opt/homebrew/Library/Homebrew/vendor/portable-ruby/4.0.5_1/bin/ruby
CPU: 24-core 64-bit arm_blizzard_avalanche
Clang: 21.0.0 build 2100
Git: 2.54.0 => /opt/homebrew/bin/git
Curl: 8.7.1 => /usr/bin/curl
macOS: 26.5-arm64
CLT: 26.5.0.0.1777544298
Xcode: 26.6 => /Applications/Xcode-26.6.0-Release.Candidate.app/Contents/Developer
Metal Toolchain: N/A
Rosetta 2: false

Output of brew doctor

Not relevant

Description of issue

After updating to Homebrew 6.0.0, I reviewed the untrusted taps.

I realized that I don't need most of the casks from untrusted taps, but it seems that it's not possible to uninstall packages from untrusted taps, which seems counter-intuitive.

If someone installs Homebrew 6 and realizes they rely on some taps they don't trust, why do they need to explicitly trust them (against their explicit wish to not trust them) just so they can uninstall the previously installed packages? Is that an oversight, or am I using it wrong?

FYI, this is what I did: brew uninstall sikarugir
And this is the output:

Error: Refusing to load cask sikarugir-app/sikarugir/sikarugir from untrusted tap sikarugir-app/sikarugir.
Run `brew trust --cask sikarugir-app/sikarugir/sikarugir` or `brew trust sikarugir-app/sikarugir` to trust it.

I also can't untap the tap, because I still have have a formula or cask installed.

For now, it seems like the only way to remove an untrusted package is:

• Trust the tap (against all common sense)
• Uninstall the casks or formulas depending on it
• Untap the tap
• Explicitly untrust the tap, since untapping doesn't remove previously granted trust

In this case I do actually trust the sikarugir tap but still wanted to uninstall the tool because I don't need it anymore, but what if I actually don't trust the tap?

[a-gn]

Does uninstalling a cask require running arbitrary code coming from the tap? Claude tells me that "Homebrew now refuses to even load the cask definition from an untrusted tap, even for a read-only operation like uninstall". Not sure if it's right.

[botantony]

Does uninstalling a cask require running arbitrary code coming from the tap?

Yes, casks may contain Ruby code that executes during uninstallation (https://docs.brew.sh/Cask-Cookbook#stanza-uninstall)

[klapauciusisgreat]

And, to add this report, it's not even possible to untap while an untrusted formula or cask is still installed. This is somewhat annoying. It would be nice to have error messages explaining how to manually uninstall or untap.

[agingorange]

It's also not possible to use brew to see which other things depend on it, without trusting it, as I found out with ansi2txt. It kind of locks you in a situation without being able to get out of it.

[SMillerDev]

Any time you update your software, homebrew tells you something's wrong and then asks for explicit permission to keep whatever went wrong, or live with the nag forever. Is there really no other choice?

You have three choices to resolve the warnings per tap:

• remove the software that brew doesn't know whether to trust
• trust the specific packages you have installed that you trust
• trust the whole tap so any package in it inherits that trust
• technically you can also just ignore the warnings, but that doesn't seem like a real option

[BitGrub]

I would love to help, (or just give suggestions, realistically) but I don't understand what is happening or why! I've tried removing the three affected packages I have because thankfully they're not necessary, but as this issue suggests, homebrew seems to require explicit trust first.

I know what I don't know, and my infinite wisdom is telling me not to mess with permissions I don't understand. I'll get to investigating each of my the affected packages eventually.. probably... But for now I'd rather just find a way to delete them without running any 'untrusted' scripts

[SplittyDev]

If you don't trust the software you installed before, you can just leave it untrusted.

Well yes, but you can't uninstall it, or even check what depends on it without trusting it again. And if you trust it to uninstall it, it remains trusted forever, because brew doesn't tell you that untapping a tap keeps the previously granted trust. I can't imagine a scenario in which I'd want to untap a tap without also removing it from the trusted taps.

[SMillerDev]

because brew doesn't tell you that untapping a tap keeps the previously granted trust. I can't imagine a scenario in which I'd want to untap a tap without also removing it from the trusted taps.

That seems like a bug, could you file an issue for that?

[SMillerDev]

I'll get to investigating each of my the affected packages eventually.. probably... But for now I'd rather just find a way to delete them without running any 'untrusted' scripts

There is no way to do that unfortunately. Realistically though, if I was an attacker I'd probably put the base code in the install path instead of uninstall. And the packages might also be just fine.

Personally I'd just take the risk for things I'd want to uninstall and brew trust --formula something && brew rm something

[zboralski]

You can't even use brew info package without trusting its tap.

brew info ipsw
Error: Refusing to load cask blacktop/tap/ipsw from untrusted tap blacktop/tap.
Run `brew trust --cask blacktop/tap/ipsw` or `brew trust blacktop/tap` to trust it.

[SMillerDev]

That is correct, since that would require executing its Ruby code. And that's what the trust system is protecting against.

You don't have to trust the whole tap though, you can also trust a single package

[klapauciusisgreat]

I believe a reasonable suggestion would be to have an option that allows an untap or uninstall of a now untrusted item without having to turn on trust for the item for anything than this one time operation. Bonus for showing which untrusted file get executed or the relevant config file for making a check easier. The current solution - trust, then uninstall, then untrust works, but is a) awkward and b) not very secure as many people will forget the last step - untrust.

…

On Tue, Jun 16, 2026 at 21:28 Sean Molenaar ***@***.***> wrote: I'll get to investigating each of my the affected packages eventually.. probably... But for now I'd rather just find a way to delete them without running any 'untrusted' scripts There is no way to do that unfortunately. Realistically though, if I was an attacker I'd probably put the base code in the install path instead of uninstall. And the packages might also be just fine. Personally I'd just take the risk for things I'd want to uninstall and brew trust --formula something && brew rm something — Reply to this email directly, view it on GitHub <#6891?email_source=notifications&email_token=AGMK7COR6ZK7JCO6PSJ4PGT5AJCBHA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZTGM2DMNZRUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17334671>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGMK7CMAWJG72IROTBJSGPL5AJCBHAVCNFSNUABIKJSXA33TNF2G64TZHMZDSMRSGY3DSMJTHNCGS43DOVZXG2LPNY5TCMBSGQZDAMZQUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AGMK7CPSOOSYJAG3GMWGLVT5AJCBHA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZTGM2DMNZRUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/AGMK7CI5BJHTLQ42K4OA2Y35AJCBHA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZTGM2DMNZRUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>

[SMillerDev]

I believe a reasonable suggestion would be to have an option that allows
an untap or uninstall of a now untrusted item without having to turn on
trust for the item for anything than this one time operation.

So... trust it to run arbitrary code without telling the user? That seems a bit counter to the whole idea of the feature.

[SplittyDev]

So... trust it to run arbitrary code without telling the user? That seems a bit counter to the whole idea of the feature.

I don't think that's what they meant. I believe they meant something like this:

• brew untap --trust some/tap
• brew uninstall --trust somepkg.

One-time, explicit trust to do the operation that requires trust without having to "globally" trust the tap or package. Because right now, you have to trust, then untap, then untrust, which is highly unintuitive and easy to get wrong.

So essentially, you'd be able to trust the operation involving the package once, rather than globally trusting the package or tap.

It requires two less commands (trusted uninstall vs trust -> uninstall -> untrust), it's much more intuitive to use, and I'd argue it's more secure as well, since it's easy to forget (and hard to even know in the first place) that previously granted trust isn't removed when the tap or package is removed.

[klapauciusisgreat]

more like untap --trust_only_this_time some/tap so you don't have to remember to untrust after the deletion. BTW, this is not just hypothetical. All the emacs-plus/emacs-mac packages are untrusted at the moment. That probably affects quite a few people.

…

On Wed, Jun 17, 2026 at 12:49 AM Marco Quinten ***@***.***> wrote: So... trust it to run arbitrary code without telling the user? That seems a bit counter to the whole idea of the feature. I don't think that's what they meant. I believe they meant something like brew untap --trust some/tap, or brew uninstall --trust somepkg. One-time, explicit trust to do the operation that requires trust without having to "globally" trust the tap or package. Because right now, you have to trust, then untap, then untrust, which is highly unintuitive and easy to get wrong. — Reply to this email directly, view it on GitHub <#6891?email_source=notifications&email_token=AGMK7CLFH3COR7AE3SF3MUT5AJZVHA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZTGM3DSNRXUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17336967>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGMK7COQZDFPK4IXZ5URWXL5AJZVHAVCNFSNUABIKJSXA33TNF2G64TZHMZDSMRSGY3DSMJTHNCGS43DOVZXG2LPNY5TCMBSGQZDAMZQUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AGMK7CLBIRCHIXH22QQZAP35AJZVHA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZTGM3DSNRXUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/AGMK7CIEM4HMYL3BVDAPQ4T5AJZVHA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZTGM3DSNRXUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>