Should the Ghidra cask be removed due to quarantine issues? about homebrew-cask HOT 14 OPEN

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.

from homebrew-cask.

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.

from homebrew-cask.

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.

from homebrew-cask.

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.

from homebrew-cask.

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.

from homebrew-cask.

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.

from homebrew-cask.

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.

from homebrew-cask.

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?

from homebrew-cask.

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

from homebrew-cask.

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.

from homebrew-cask.

@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

from homebrew-cask.

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?

from homebrew-cask.

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.

from homebrew-cask.