Should the Ghidra cask be removed due to quarantine issues?

[matt-phylum]

Verification

• This issue's title and/or description do not reference a single formula e.g. brew install wget. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.

Provide a detailed description of the proposed feature

Homebrew should remember when casks are installed with --no-quarantine so it doesn't reenable quarantine when upgrading them. As it is, the --no-quarantine option is not very usable.

What is the motivation for the feature?

The Ghidra project does not codesign important components of Ghidra (NationalSecurityAgency/ghidra#1559 (comment)). In practice, this means when you brew install --cask ghidra (https://formulae.brew.sh/cask/ghidra), you get a broken version of Ghidra which can't be used for binary analysis.

There is no real solution. Either you circumvent Gatekeeper by removing the quarantine attributes from the shipped binaries, or you circumvent Gatekeeper by building your own binaries without the quarantine attribute (by running unsigned scripts to build unsigned source code that is equally as trustworthy as the precompiled binaries).

The Homebrew project will not circumvent Gatekeeper in the cask (#169538 (comment)).

As a workaround, you can install the package with brew install --no-quarantine ghidra (#137489 (comment)). However, Homebrew forgets that it's supposed to use --no-quarantine as soon as the installation completes. After a few weeks, brew upgrade breaks Ghidra, and attempting to open a new file in Ghidra results in repeated error dialogs from Mac OS telling you that you aren't allowed to run those executables and broken Ghidra functionality.

Homebrew does record --appdir, --keyboard-layoutdir, --colorpickerdir, etc into .metadata/config.json, but it does not record --no-quarantine.

How will the feature be relevant to at least 90% of Homebrew users?

This is relevant to nearly 100% of users of similarly broken casks, but this is the only one I know of.

What alternatives to the feature have been considered?

If this feature is not added, the Ghidra cask should be removed because it does not work. Maybe it could be replaced with a Ghidra formula because formulas turn unsigned source code into executable code without being constrained by Gatekeeper.

[MikeMcQuaid]

I don't think we should persist flags like this because that disable security features.

If this feature is not added, the Ghidra cask should be removed because it does not work.

Moving to homebrew-cask and CC @Homebrew/cask for discussion.

My position: if literally nothing in this cask works at all for anyone without --no-quarantine: it should be removed.

If some features are still useful without: it should stay, perhaps with some caveats added.

[p-linnane]

I am not in favor of this. I'm actually not even a fan of --no-quarantine existing at all. Reducing the security features of macOS should always be a last ditch sort of thing, and I don't believe we should be making it easier to do.

If the cask doesn't work without --no-quarantine, it should not be in our repos.

[MikeMcQuaid]

If the cask doesn't work without --no-quarantine, it should not be in our repos.

I agree with this. I would also like to see us remove --no-quarantine, I'm game to deprecate it in the next major/minor release.

I think @p-linnane and I are aligned but others may not be: it depends on the definition of "work". Some people claim a given formula/cask "does not work" or "is broken" if any single feature is broken in any configurations. Personally, I consider it to mean "the core functionality is broken for the majority of users on supported platforms". It is unclear to me which side this specific cask falls into.

[p-linnane]

A good example of a 'broken' cask is vmware-fusion. It complains and pops Gatekeeper warnings for certain components, but it works. If one really needs it to stop, they can use xattr to remove the quarantine attribute manually.

[matt-phylum]

It's broken for me. I open a file in the CodeBrowser and start getting repeated Gatekeeper errors. Symbols are not demangled and the decompilation panel displays an error instead of the decompilation.

I don't know if there are other workflows that people do in Ghidra where they wouldn't be affected. Maybe if you're looking at hand-written executables there is no symbol mangling and you just want to view the disassembly instead of decompilation?

I was making sure I wasn't missing something with installation and kept finding stuff like this:

• https://lachy.io/articles/properly-installing-ghidra-on-an-m1-mac Install with Homebrew and replace the unsigned executables
• https://jonathandionne.com/posts/install-and-run-ghidra-on-mac-m2-silicon/ Install with Homebrew and replace the unsigned executables
• https://www.youtube.com/watch?v=LJz6MdzEmjM Install JDK with Homebrew, build Ghidra from source
• https://gist.github.com/stonegray/0bfdabff5a735aaa0816d39a9144aae4 Install with Homebrew and remove quarantine attributes
• https://stackoverflow.com/questions/70640568/decompiler-not-working-in-ghidra-disassembler Install from GitHub, "Allow Anyway"
• https://qiita.com/zakkied/items/2587711b5a408602093b Install with Homebrew and remove quarantine attributes
• https://yonghwi-kwon.github.io/class/enee459b/data/Installing_ghidra.pdf Install with Homebrew and replace the unsigned executables

Of course, if somebody installed and it just worked, they wouldn't be searching for or posting solutions online, so I wouldn't be finding many pages saying "I installed it and it just worked," but it seems like a common problem that it doesn't work.

[razvanazamfirei]

My position: if literally nothing in this cask works at all for anyone without --no-quarantine: it should be removed.

I agree with this. I would also like to see us remove --no-quarantine, I'm game to deprecate it in the next major/minor release.

I agree with this, but if we are to remove --no-quarantine, we should consider removing casks without code-signing that have been grandfathered in. Lately, we have pushed back against including any instructions on how to circumvent security measures, including the mentioning of --no-quarantine. However, my rationale was that if someone was savvy enough to understand the quarantine, they would be able to find the --no-quarantine flag by themselves.

However, if we end up deprecating the flag and we keep unsigned casks, we'll be in a weird situation where we distribute casks we know will not work for most people, while disabling any functionality on the homebrew side to make it work.

Again, I think the solution should be increasing the security posture and deprecating --no-quarantine, but we need to be clear on how we handle existing casks. IMO, the change should be included in a major release with plenty of notice to all involved.

[p-linnane]

I agree with this, but if we are to remove --no-quarantine, we should consider removing casks without code-signing that have been grandfathered in.

Agreed. We haven't been accepting new casks that aren't code-signed for quite a while. If we can effectively look back and see what still exists, it would be great.

However, if we end up deprecating the flag and we keep unsigned casks, we'll be in a weird situation where we distribute casks we know will not work for most people, while disabling any functionality on the homebrew side to make it work.

Yes, agreed here.

IMO, the change should be included in a major release with plenty of notice to all involved.

We can do this in a minor release, don't need to wait for a major one.

[bevanjkay]

Agreed. We haven't been accepting new casks that aren't code-signed for quite a while. If we can effectively look back and see what still exists, it would be great.

The codesigning audit is currently only applied with the --strict flag, which is not applied to existing casks. This could be turned on, and then we would deprecate/disable the casks?

[krehel]

My position: if literally nothing in this cask works at all for anyone without --no-quarantine: it should be removed.

Agreed! 👍

The codesigning audit is currently only applied with the --strict flag, which is not applied to existing casks. This could be turned on, and then we would deprecate/disable the casks?

I would support enabling this all the time, for the existing casks.

It would be good to see the metrics for how many software have come in that are broken. I broadly agree with everything above, with a few thoughts

• Assessing what exists and is popular, despite being broken, to handle some kind of transition. Examples like Ghidra probably fit this criteria IMHO to have some kind of doc on "offboarding", as it were.
• Some level of communication and structure for when software starts being removed or deprecated, and what those are.
• Generalized "principles of least surprise" and all that

[MikeMcQuaid]

Agreed. We haven't been accepting new casks that aren't code-signed for quite a while. If we can effectively look back and see what still exists, it would be great.

Also agreed.

The codesigning audit is currently only applied with the --strict flag, which is not applied to existing casks. This could be turned on, and then we would deprecate/disable the casks?

Yes, I think that's probably the best course of action now we've verified it's working nicely.

[p-linnane]

@matt-phylum FWIW, I have an unofficial tap for unsigned casks. If you're concerned about Ghidra's removal, feel free to install it from my tap: https://github.com/p-linnane/homebrew-cask-unsigned

[daeho-ro]

What happen to the unsigned casks in the custom tap if --no-quarantine command is deprecated? There are many packages without codesign and so I also uses the custom tap to install and manage some packages. When I run them, I prefer to use the option --no-quarantine to easy run. But it seems that I have to turn off it manually from settings after the deprecation, right?

[MikeMcQuaid]

What happen to the unsigned casks in the custom tap if --no-quarantine command is deprecated?

They will also be deprecated, disabled and eventually removed.

These casks are broken on Apple Silicon anyway which is the majority platform for us at this point.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.