{"id":24447,"date":"2019-02-27T16:27:24","date_gmt":"2019-02-27T21:27:24","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=24447"},"modified":"2024-10-09T15:38:46","modified_gmt":"2024-10-09T19:38:46","slug":"bbedit-12-6-to-return-to-the-mac-app-store","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2019\/02\/27\/bbedit-12-6-to-return-to-the-mac-app-store\/","title":{"rendered":"BBEdit 12.6 to Return to the Mac App Store"},"content":{"rendered":"

Bare Bones Software<\/a> (tweet<\/a>, MacRumors<\/a>):<\/p>\n

BBEdit is now a sandboxed application.<\/p>

[…]<\/p>

Without unrestricted access to your files and folders, many of BBEdit’s most useful features, from the basic to the most powerful, won’t work at all; or they may misbehave in unexpected ways. At the very least, this hinders your ability to work done.<\/p>

In order to resolve this fundamental conflict between security and usability, we have devised a solution in which BBEdit requests that you permit it the same sort of access to your files and folders that would be available to a non-sandboxed version.<\/p>

For this reason, the first time you start BBEdit, it will prompt you to allow this access. The prompt will not be repeated; so if you decline to allow this access and later reconsider, go to the Application preferences, and click on the “Allow” button in the “Sandbox Access” section.<\/p><\/blockquote>\n\n

It saves a security-scoped bookmark that allows access to every volume on your Mac.<\/p>\n\n

BBEdit being able to return to the Mac App Store is great news for customers (modulo bugs<\/a>) and for Bare Bones, but I’m not sure what it means for the store in general. Although there has finally been some progress<\/a>, this feels like Apple giving up. They can’t or don’t want to really fix<\/a> the sandbox to work well with pro apps, but they do want them to be in the store, so they’ll just let them ask for blanket permissions. BBEdit gets to be in the store, and Apple gets to say that everything<\/a> (except Xcode) is sandboxed, even though it’s kind of security theater<\/a>.<\/p>\n\n

This doesn’t bother me with respect to BBEdit. I’ve been running it unsandboxed for almost 25 years, so I trust the app, and this is not a decrease in security.<\/p>\n\n

But what about other apps? Is any<\/em> app now allowed to request persistent access to the entire file system? Technically, this has been possible since OS X 10.7, but few if any apps did it. I think everyone assumed it would lead to rejection. Has the policy changed<\/a>? Or does App Review decide this on a case-by-case basis? How intrusive do the folder access prompts have to be before you can just get access to everything at once?<\/p>\n\n

I don’t think users really understand that this is what clicking the button in an open panel is doing. And there’s no way to see which applications are maintaining access to which folders. It’s just not very clear what’s going on. Apple is kind of shifting the blame if anything bad happens. It can’t be their fault because the user “consented.”<\/p>\n\n

More security-related changes:<\/p>\n

When running on macOS 10.14.1 or later, BBEdit now uses built-in OS support for performing operations which require privilege escalation, namely authenticated saves and (if escalation is necessary) installation of the command-line tools.<\/p>

[…]<\/p>

AppleScripts are now run in a separate process, which means that any previous differences in scripting behavior as the result of running a script within BBEdit or from the Script Editor should be a thing of the past.<\/p>

[…]<\/p>

If BBEdit can’t send save or close notifications because you\npreviously denied it permission to send Apple Events to the\napplication which needs them (usually a file transfer client from\nwhich you used “Edit in BBEdit”), you’ll now get an alert to this\neffect; the help button in the alert takes you to\na page which explains how to fix things<\/a>.<\/p><\/blockquote>\n\n

My understanding is that “Edit in BBEdit<\/a>” can no longer work with arbitrary apps, only those that have been pre-listed in BBEdit’s com.apple.security.temporary-exception.apple-events<\/code> entitlement. Those are the only apps that it can send Apple events to. It’s kind of a drag. I once added “Edit in BBEdit” support to an app and didn’t need to get permission from anyone. (The app was Apple Mail, and said support has long since been broken by Mail’s sandboxing blocking Apple events.)<\/p>\n\n

At first, I thought, I guess this does<\/em> need to be clamped down. BBEdit has extensive AppleScript support, so if you give it full file access, then any FTP client or blog editor would also be able to get full access, just by asking BBEdit to do its bidding. But BBEdit’s sandboxing and entitlement aren’t actually protecting against that because any<\/em> app can send events to<\/em> BBEdit. That hasn’t changed. The real issue is that any sandboxed app that lists BBEdit in its<\/em> com.apple.security.temporary-exception.apple-events<\/code> can get full access. (I think; I haven’t tested this.) It’s obvious why you might not want to allow an app to script Finder or Terminal, but less so for a text editor. Is this an actual problem? I don’t know. These days I see a lot of people talking about theoretical Mac malware but not about problems it’s causing in the wild. And it’s no less secure than before, just more surpising because this can happen with two sandboxed apps from the store.<\/p>\n\n

Previously:<\/p>\n