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
Handling Casks #40
Comments
Maybe it is possible to make a custom |
Follow multi-user homebrew guide: https://medium.com/@leifhanack/homebrew-multi-user-setup-e10cb5849d59 |
Actually I had also encountered such problem when implementing my own auto-updater for Mac, MacDaily. So basically, my solution was to temporarily set My implementation for the AppleScript is at macdaily/res/askpass.applescript, which was originally inspired from another Homebrew formula called |
Out of curiosity @JarryShaw , how hard was it to implement? Tempted to look further into it and attempt it myself, especially if no one else has got around to it yet :) |
Setting |
@CiaronHowell It was quite a simple task with some tests lol
I don't quite like this idea... 🔗 |
NOPASSWD should be acceptable as you would only allow the auto update command to be executed. Installation should be a manual action to make the user aware, auto updating with sudo rights is inherently a security risk. That is also why I would understand for brew not to support this. However I hope it will exist anyway, perhaps unofficially. |
Thank you, I'll give it a go soon 😄 |
I made a one-liner script to store my password in the keychain following this guide. It should be a lot more secure than storing your password in plaintext. |
Could you share details of how you use that script? |
I added |
This could be a potential solution if we're able to capture which cask requires sudo privilege |
note that the script in the guide must be slightly modified, since SUDO_ASKPASS expects a script that spits just your password to standard out when invoked. Here's what my getpass.sh contained: pw_name="CLI"
pw_account="matt"
if ! cli_password=$(security find-generic-password -w -s "$pw_name" -a "$pw_account"); then
echo "error $?"
exit 1
fi
echo "$cli_password" |
I was going to suggest this, but you beat me to to it! I check which process is requesting sudo access with |
I wonder if pinentry could be used via |
TL;DR solution (using getpass.sh)(assuming your username is "mateowang" and password is "password123")
|
Any security risks when using this? |
You don't need to modify |
Yes, it can. milanvarady/Applite#5 (comment) |
Yes, it works and is in my opinion the most secure and user-friendly solution. SetupDependency
Create Password Script
#!/bin/bash
PW="$(printf "%s\n" "SETOK OK" "SETCANCEL Cancel" "SETDESC homebrew-autoupdate needs your admin password to complete the task" "SETPROMPT Enter Password:$
echo "$PW" Invoke Password Script when homebrew-autoupdate runs
add: TestTest Password Dialog
Test homebrew-autoupdate
|
I guess you could also use TouchID: https://github.com/jorgelbg/pinentry-touchid |
It would be awesome if we could use the touch ID. |
@swissbuechi Out of curiosity, why do you invoke a subshell and then echo the password, when it works as well to not do that? |
I'm glad you like it 👍🏻
EDIT: @toobuntu was right, I did not understand his initial question about invoking a subshell, he already fixed it in PR: #128 |
@DomT4 I think this issue could now be closed. |
Issue:
sudo
to upgrade can block this command from executing successfully when people useautoupdate
to executeupgrade
on their behalf, because of the hang on silently waiting for sudo authorisation.brew upgrade
withsudo
, immediately bailing on the command, meaning we can't execute the Cask upgrade command as root to work around the issue.Potential Fix:
sudo
usage to upgrade, only passing those non-sudo Casks to theupgrade
command.Problems with Fix:
sudo
Casks behind intentionally; would need to find a way to gracefully notify the user to their presence & reason for not upgrading.sudo
has a very real potential to be fragile and prone to breaking.Hacky Temporary Workaround
SUDO_ASKPASS
as Homebrew seems to intentionally support that for non-interactive installs, and works when tested locally.sudo
passwords sat on the filesystem unguarded in plaintext.Related Issues:
The text was updated successfully, but these errors were encountered: