mas options to overcome install/purchase/upgrade/lucky failures from macOS 26.1, 15.7.2 & 14.8.2

[rgoldberg]

Since Brew Bundle uses mas, I wanted to check with Homebrew personnel:

macOS 26.1, 15.7.2 & 14.8.2 all require an Apple-only entitlement to connect to installd.

That breaks the Apple private framework that mas uses for its install, purchase (aka get), upgrade (aka update) & lucky commands.

mas can work around this by calling /usr/sbin/installer, which requires root permission.

The forthcoming mas 4.0.0 must be run with root permission for any of the aforementioned 4 commands to work.

That isn't ideal for scripts, but people can modify their sudoers to allow sudo to be used without a password.

mas wouldn't need to use sudo, however if it was rewritten & repackaged to use a privileged helper executable. That would require mas to be distributed signed, so would require mas to migrate from a formula to a cask.

It would also require the user to allow the helper executable to run as a background process, also requiring user acceptance when mas is installed.

Would it be beneficial to have mas available using a privileged helper executable?

Maybe mas could use a privileged helper process if it is running, otherwise mas could still work if it is called with root permissions. I don't know if that would be easy to do, either in a single packaging or in separate packagings (one for helper, one for root permissions).

Signing mas & using a privileged helper executable would take some time to implement (coding & packaging the privileged helper app, signing the executable & installer, possibly switching build system from SwiftPM to Xcode, etc.), while the sudo version is almost ready for the 4.0.0 release.

If mas stays with requiring root permissions, mas can provide instructions about how to setup sudoers from the error message when any of the commands that require root are run without such permissions. I don't think that I want to automate setting up sudoers to prevent messing it up. I don't want to be held responsible if someone else messes up their sudoers, so maybe even instructions might be bad. Maybe mas should just provide a URL to third-party instructions.

FYI: 4.0.0 will probably only update the progress bar for the download portion, not for the install portion. I don't want to waste much time on logging output right now, especially since I will probably completely refactor the output system to support the forthcoming JSON output option & installing / upgrading in parallel.

[MikeMcQuaid]

Thanks for the heads up @rgoldberg.

That isn't ideal for scripts, but people can modify their sudoers to allow sudo to be used without a password.

Just for any users reading this: I would strongly recommend against doing this, even if just for /usr/sbin/installer, as it provides the ability to run any arbitrary code as root for pretty much any non-sufficiently-sandboxed application.

Would it be beneficial to have mas available using a privileged helper executable?

No. I don't like the security profile this introduces and puts a lot more trust in a tool that hasn't yet earned it.

I don't want to be held responsible if someone else messes up their sudoers, so maybe even instructions might be bad.

I would suggest not recommending users do this then and that Homebrew should also not recommend this.

---

I think the best trust model here is for mas to use sudo and to educate users when/why it's required, somewhat similar to how brew --cask commands do. Unfortunately, that does strip away another advantage from using mas over casks so it may be we need to consider the future of mas in brew bundle if the experience degrades to the point we get too many support issues.

[MikeMcQuaid]

I can try to provide a PR for brew bundle, but it would be best if someone from Homebrew can write it / triple check my PR, as I don't know Ruby or the brew bundle code.

Thanks! I will review. I recommend using system_command with the sudo flag for the calls to mas.

Later versions of mas might ask to elevate to root for the appropriate commands.

Will these still work as expected if run with sudo? Ideally the public-facing API wouldn't change twice here in a non-long time period.

[rgoldberg]

@MikeMcQuaid I've released mas 4.0.0. I have submitted a PR to update the formula for homebrew-core.

The mas executable Swift binary is now wrapped by an executable zsh wrapper that uses sudo to call commands that require root privileges.

Brew bundle users must supply root privileges for mas install & mas upgrade. Root privileges are unnecessary for mas list & mas outdated, so users need supply root privileges only when an app is installed or updated, neither for dumping a Brewfile nor for checking if MAS apps are outdated.

[rgoldberg]

@MikeMcQuaid I am redoing how mas handles root privileges.

I was able to allow Swift to call sudo, with sudo properly wired to the terminal by using low-level C macros, which isn't possible via a high-level Swift Foundation Process.

This obviates the need for the shell wrapper, and provides other benefits.

I'm redoing mas to work with this new paradigm.

Please see this mas issue comment.

The most pertinent items for Homebrew in the comment are the last 2 in the main list: items 6 & 7.

Would you be amenable to brew bundle being changed as outlined in 6?

If so, which of the "upsert" options from 7 do you recommend? Or do you recommend an alternative "upsert" interface or an alternative subcommand or flag name?

Thanks.

[MikeMcQuaid]

@rgoldberg I would rather we can just repeatedly call mas and have it only prompt the first time and not others, using usual sudo timeout semantics.

[rgoldberg]

@MikeMcQuaid Using normal sudo timeout semantics works for me. Thanks for the feedback.

I anticipate that the updated root privileges handling (plus maybe some other cleanup & improvements) should be out within a few days as mas 4.1.0.

I thought (obviously incorrectly) that you wanted root privileges limited to just the individual calls for which they were granted, given your prior mention of sudo -k, and given the warning output by brew bundle rejecting being called with root privileges.

Obviously, being called with root privileges is less secure than sudo credentials being established for the user-configurable sudo timeout by a command called by brew bundle, so it makes sense that the former would be unacceptable while the latter acceptable; I just interpreted potential security guidelines as stringently as possible because I wanted to avoid causing security issues for anyone.

Thanks again.