Everyday Usage

[ppo]

Output of brew config

HOMEBREW_VERSION: 4.5.8
ORIGIN: https://github.com/Homebrew/brew
HEAD: c19f08b3e8ea46ba94bd9315c46c0dda10ead31c
Last commit: 4 days ago
Branch: stable
Core tap JSON: 27 Jun 11:14 UTC
Core cask tap JSON: 27 Jun 11:14 UTC
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_MAKE_JOBS: 10
Homebrew Ruby: 3.4.4 => /opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.4.4/bin/ruby
CPU: deca-core 64-bit arm_donan
Clang: 16.0.0 build 1600
Git: 2.50.0 => /opt/homebrew/bin/git
Curl: 8.7.1 => /usr/bin/curl
macOS: 15.5-arm64
CLT: 26.0
Xcode: 16.4
Rosetta 2: false

Output of brew doctor

(not relevant)

Description of issue

It seems that executing brew terminates the sudo session immediately (at least with update, outdated, and missing; NOT help). Is that normal, the desired behavior?

If so, how can I make brew upgrade --cask ask only once my password? (As I launch it and do something else, then forget to check)

% is_sudo_active
[13:26:14] sudo NOT active

% sudo -v
Password:

% is_sudo_active
[13:26:37] sudo active

% brew update
==> Updating Homebrew...
Already up-to-date.

% is_sudo_active
[13:26:43] sudo NOT active

function is_sudo_active() {
  local s="active"
  ( sudo -n true 2>/dev/null ) || s="NOT active"
  echo "[$(date +%H:%M:%S)] sudo ${s}"
}

[SMillerDev]

Is that normal, the desired behavior?

Yes, see Homebrew/brew#17694 it's a security measure.

[ppo]

Thanks @SMillerDev.

Security, OK but in the meantime the UX is terrible! Asking for our password once at the beginning but not for every single package, moreover at unknown moments during a long-running task (that often runs in the "background"/in a non-visible window).

It's surely a good idea to for that for install (directly or indirectly via dependencies). But is it for upgrade? And especially for update, outdated, missing…? Especially when managed via bundle.

Isn't or shouldn't there be a way to configure that in our Brewfile (via args for example), allowing to cherry-pick which packages we trust to use sudo?… I guess that currently it's a brute force "kill sudo" every time a command is executed… and I don't know if we can force asking for password when sudo is active.

There must be a way to improve the UX while ensuring security.

[SMillerDev]

It's surely a good idea to for that for install (directly or indirectly via dependencies). But is it for upgrade?

An upgrade is exactly the same as an install. And casks might need it.

And especially for update, outdated, missing…? Especially when managed via bundle.

Bundle doesn't really factor into it. But if you can figure out a way to make it more selective I'll happily review a pull request. In the meantime this was the best way I could think of to avoid giving anything running in or after brew sudo access.

[ppo]

Conceptually, from a security POV, I think that an upgrade is less dangerous/suspect than an install – make sure the user really wants to install a new package, then we can be more relaxed for upgrades (if the user wants that). Same thing for bundle, if the user put it there, we can be more relaxed.

Sorry, no time to dive into the code… especially for that kind of stuff.

For bundle, my idea was something like: "if not bundle[package].args.allow_sudo: force_ask_password" (allow_sudo being false by default).

[SMillerDev]

Conceptually, from a security POV, I think that an upgrade is less dangerous/suspect than an install

Not sure why, they can create the same amount of damage.

Not allowing sudo at all is not a solution either because that will break an entire type of software installs in brew.

[gromgit]

@ppo, if the issue you're facing is Homebrew's resetting of sudo credentials forces reauthentication after brew, there's a simple workaround for that. Since sudo caches credentials based on username and tty, simply run brew in a separate pseudo-tty environment. The script command is an easy way to do that:-

faketty() {
  if [[ $(uname -s) == Darwin ]]; then
    # BSD/macOS script
    script -qF /dev/null "$(printf "%q " "$@")"
  else
    # GNU/Linux script
    script -qefc "$(printf "%q " "$@")" /dev/null
  fi
}

% sudo -v            # requires password
% sudo ...           # doesn't require password
% faketty brew ...   # may require password
% sudo ...           # doesn't require password

[gromgit]

In that case, SUDO_ASKPASS might be what you need. Homebrew passes that env var through, so:-

#!/usr/bin/env bash
# !!! HERE BE DRAGONS !!!
# Understand your environment and threat model before proceeding...
askpass=/tmp/p.sh
cat <<EOS >"$askpass"
#!/bin/sh
echo this_is_my_sudo_password
EOS
chmod +x "$askpass"
trap 'rm -f "$askpass"' EXIT

export SUDO_ASKPASS=$askpass
brew this ...
brew that ...
brew other ...

[ppo]

Thanks but SUDO_ASKPASS doesn't seem to work… or what I did is not correct? 🤔

export SUDO_ASKPASS="${HOME}/bin/askpass.osascript"

With ${HOME}/bin/askpass.osascript:

#!/usr/bin/osascript
return text returned of (display dialog "Type your password" with title "Administrator password needed" default answer "" buttons {"Cancel", "OK"} default button "OK" with hidden answer)

[gromgit]

What exactly does "doesn't seem to work" look like?

Also note that the binary pointed to by SUDO_ASKPASS will be run on each separate brew invocation that runs sudo, so you probably want to store it in a (preferably secure) cache somewhere, instead of repeatedly prompting the user.

[ppo]

The binary pointed by SUDO_ASKPASS is never called.

[gromgit]

How are you calling it? I put your exact script in my ~/tmp/askpass.osascript, and...

When I type in my password in the dialog box, the upgrade completes successfully.