Ghidra 11.3.2 (new formula)

[Tokarak]

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

  * line 5, col 3: `url` (line 5) should be put before `version` (line 4)
  * line 27, col 119: Line is too long. [124/118]
  * The homepage URL https://www.nsa.gov/ghidra is not reachable (HTTP status code 403)
  * Stable: version 11.3.2 is redundant with version scanned from URL
  * Binaries built for a non-native architecture were installed into ghidra's prefix.
    The offending files are:
      /opt/homebrew/Cellar/ghidra/11.3.2/Ghidra/Features/FileFormats/data/sevenzipnativelibs/Mac-x86_64/lib7-Zip-JBinding.dylib	(x86_64)

All for good reason:

• Line cannot really be wrapped (can it?)
• nsa blocks bot requests, I'm guessing
• url-version order is reversed because of variable interpolation.

---

• Suceeds ghidra 9.0 #37656, since Ghidra should now be fully open-source. (I shamelessly stole the test case from that PR too.)
• This formula is designed to behave identically to the cask. However, it now has no intel components when built on arm (see the gradle buildNative line), which resolves issues like Decompiler executability support for aarch64/arm64 (linux, and possibly macOS) NationalSecurityAgency/ghidra#3622.

[github-actions]

Thanks for contributing to Homebrew! 🎉 It looks like you're having trouble with a CI failure. See our contribution guide for help. You may be most interested in the section on dealing with CI failures. You can find the CI logs in the Checks tab of your pull request.

[Tokarak]

Things I'm not sure about:

• I don't fully understand the test case. Why is it touching what seems like a java cache outside the CWD?
• Is there a conflict with the ghidra cask? Should it be resolved by renaming the executable to "ghidra", or by declaring a conflict?
• What's the homebrew stance on runtime java dependency? Is it really necessary to hard-code a 400mb dependency to a specific implementation and version of the JDK?
• Ghidra/application.properties also has information about the JDK version used to compile Ghidra; I wasn't sure how to set it at runtime.
• And, of course, I don't see how to fix the current CI failures without compromising something, as described in the main post.