wd-security 2.1.2.144 (new cask)

[unitof]

Reattempt of #173945: may have found a fix for the failing workflow, borrowed from anydesk.rb

Important: Do not tick a checkbox if you haven’t performed its action. Honesty is indispensable for a smooth review process.

In the following questions <cask> is the token of the cask you're submitting.

After making any changes to a cask, existing or new, verify:

• The submission is for a stable version or documented exception.
• brew audit --cask --online <cask> is error-free.
• brew style --fix <cask> reports no offenses.

Additionally, if adding a new cask:

• Named the cask according to the token reference.
• Checked the cask was not already refused.
• Checked the cask is submitted to the correct repo.
• brew audit --cask --new <cask> worked successfully.
• HOMEBREW_NO_INSTALL_FROM_API=1 brew install --cask <cask> worked successfully.
• brew uninstall --cask <cask> worked successfully.

---

[unitof]

It passes! See #173945 for context.

Let me know if this is cheating! But seems to handle the plist that was tripping up the workflow, which is left behind by the uninstall script.

I may have overestimated by calling this "obscure"—it's needed by anyone with a number of Western Digital drives, and is a pain to find and install from WD, thus the desire for a Cask.

Also allows us to much better handle clean uninstallation, as evidenced by our reverse engineering struggles here.

[bevanjkay]

Can we confirm that it doesn't require user-intervention on install? When I installed it locally it required an additional password outside of terminal before continuing.

It is definitely still hanging definitely for me.

[unitof]

It seems to prompt for that if Gatekeeper is enabled and it's been more that X minutes since the last time it was installs.

The prompt asks for biometrics with sudo: true, but prompts for full password when the formula doesn't call for sudo. Does that provide any clues how I might go about scripting around it?

As @bevanjkay noticed in the last PR, it seems the install .app is calling yet some other executable.

Understood if this is just a hard wall requiring interactivity—happy to bring this back to a personal tap and keep tinkering. Very happy with where it's gotten to.

[krehel]

@unitof are you using a machine with Apple Silicon? Also for @bevanjkay. I'm going to test this locally but thoughts below ⬇️

I worked on a strange issue with the mplab-xc16 cask that blocked an update for almost a year.

After a lot of tinkering on that cask, I found on Intel hardware behavior was normal, but installing on Apple Silicon produced an authentication UI similar to what is shown here, intermittently, which I assume was related to some auth caching. It also used an installer that was called directly with parameters, bypassing a .sh script.

Wondering if -

1. It's the same installer family (not directly important)
2. We don't use requires_rosetta and instead lock it down to Intel hardware with depends_on arch: :x86_64 (which solved the issue for mplab-xc16) that this issue goes away, but understanding that effectiveness is limited.

[unitof]

I am on Apple Silicon! Very interesting. Certainly worth a try. Do the test runners have any macOS security systems disabled or with non-default settings?

[unitof]

I am on Apple Silicon! Very interesting. Certainly worth a try. Do the test runners have any macOS security systems disabled or with non-default settings?

[unitof]

I am on Apple Silicon! Very interesting. Certainly worth a try. Do the test runners have any macOS security systems disabled or with non-default settings?

[bevanjkay]

Do the test runners have any macOS security systems disabled or with non-default settings?

No idea on this one. They are just the standard GitHub-provided runners.
I'm potentially okay including this depending on what we find, it passes CI.
The concern is that if it is run headlessly, or dispatched remotely, does it hang indefinitely until the process is stopped.