-
-
Notifications
You must be signed in to change notification settings - Fork 10.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
wd-security 2.1.2.144 (new cask) #174386
base: master
Are you sure you want to change the base?
wd-security 2.1.2.144 (new cask) #174386
Conversation
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 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. |
@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 Wondering if -
|
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? |
No idea on this one. They are just the standard GitHub-provided runners. |
For some reason I had in my head that Homebrew ran its own Mac Mini runners. It might be that that extra authentication window only appears on machines with TouchID sensors, similar to Safari's password fill prompts. That would explain "caching" (if you biometrically authenticate it lasts systemwide for the same action for a few minutes), and would also explain why it's working headlessly on the runners. Defer to you @bevanjkay. Would love for it to be in homebrew-cask and will keep tinkering if I find improvements, but understand if it needs to be a private tap. |
I do have an Intel laptop with a TouchID I can test on. I have no ARM machines without TouchID sensors though. Will try to get to in the next day. |
Well we know it works on headless M1 Macs without biometric sensors from the runners, I think. I just tested installing over SSH on my headless M1 Mac mini running Seqoia beta and the installer script failed while Homebrew thought it was a success, so I'm going to look into that separately. However it did properly prompt for sudo password and did not hang on biometric, so it seems likely to me that's what's going on: macOS prompts for an additional biometric authentication (over sudo or other authentication) for certain filesystem actions, on machines with biometric sensors like Touch ID or Face ID. This authentication is cached for some period of time (5 or 10 minutes?) and is—as far as we can tell—indefinitely blocking an invisible to CLI scripts which trigger it. |
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:
brew audit --cask --online <cask>
is error-free.brew style --fix <cask>
reports no offenses.Additionally, if adding a new cask:
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.