-
Notifications
You must be signed in to change notification settings - Fork 91
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
Asks password multiple times in succession to upgrade each cask #241
Comments
Hey @dialex Thank you for the question. It's actually quite hard to know what's causing that, I haven't personally experienced that. Could be because of computer policy, could be also related to how the casks are defined. I'm not sure if there is actually anything we could do about it. We solely rely on |
If there is a way to know ahead whether a cask requires root to reinstall, maybe consider skipping and postponing them, so that the upgrade doesn't get stuck every other cask, because brew doesn't seem to cache sudo access anymore since that turned out to be a security issue. |
In fact I would be quite interested in how to configure it to run in full unattended mode, so the "sudo" prompt would not be needed. I am aware that this might be seen as a security issue but some users might be ok with it, so it should be an opt-in workaround. Alternatively we should have an option to tag the few packages that need sudo and avoid updating them when in unattended/scripted mode. Any suggestions? |
You can use the cask pinning feature ( For the unattended mode, I'm not sure if that's easily possible unless homebrew itself supports that. |
Yes, I had to input my password 7 times to upgrade one cask 😵
I run
brew cu -facy
each month. Today for the first time I noticed that brew cu is asking me for the device's password in quick succession. Before it would simply ask me once or twice, for specific casks, usuallydocker
orjava
. But now it's asks that many times for a single cask. This makes the script unusable.I'm using the company's laptop, could it that they changed some access policy?
The text was updated successfully, but these errors were encountered: