I don’t know if there are problems with this tool, but the App Sandbox is very configurable and every app store app is in one. It doesn’t make sense to maintain two different complex sandboxing solutions.
App Sandbox is fundamentally a way for programs to use the underlying sandbox subsystem without having to write SBPL code themselves. When a program has opted into the App Sandbox, the system applies one of these sandbox policies automatically during app initialization. The policy examines the entitlements of the application to determine which additional resources should be permitted. See /System/Library/Sandbox/Profiles/application.sb if you're curious.
By far the biggest advantage of App Sandbox is that the policy ships along with the OS. If a system framework changes what resources it accesses in a software update, Apple can update the policy so the framework functionality still works. If your app uses a custom sandbox policy, you're on your own to both notice that something has changed and to update your policy.
The downside is that the App Sandbox policy is limiting and inflexible.
That’s not true. Lots of apple’s own first party apps use SBPL to sandbox because the entitlement granularity doesn’t cut it. There’s also lots of apps on the MAS which use temporary-exception SBPL to fully sandbox.
I agree that there is no sense in operating dual systems, but entitlements can’t replace SBPL yet.
The Sandboxing and Entitlements mechanisms are very different. Sandboxing can only drop access to resources, it cannot grant access that was not already there [1]. Entitlements are all about giving additional selective privileges or to make the sandbox NOT remove access (like full disk access or debug ability ). Entitlements are bound to processes only and are non-transferable. This is in contrast to a capability based system where they can be passed around. Reasoning about capabilities is challenging because analysis effectively requires global knowledge of the system. Binding entitlements to libraries or Frameworks would turn them into capabilities.
[1] a GUI app can restore access to files by using a trusted external selection process.
Edit: change footnote reference to prevent markup error.
This is true. I was being brash. Let me say instead that the split in reasoning and evaluation as it exists on macOS in this area is rough and potentially not needed. Granted, I don't have a better answer in my back pocket, and the fact that Apple has kicked the can for 15 years on trying to harmonize these is a sign it's hard.
I took the "granularity doesn't cut it" comment to mean there aren't enough entitlements to eliminate the need for custom SBPL. Followed by a sentence about apps that have temporary exception SBPL. Combining the two seems to imply that if there were more entitlements the custom SBPL might not be necessary. In the followup you noted; the split in reasoning and evaluation is rough and potentially not needed. I read this as a conclusion of wanting to do something, but could not as there were not enough entitlements to make it work, so custom SBPL would be necessary.
If swift package manager is using it (I believe it is based on some of the error messages I occasionally see from it), deprecating it is difficult, since SPM is not distributed as an App Store app.
It's listed as the third most popular IDE after Visual Studio Code and Visual Studio by respondents to Stack Overflow's annual survey. Interestingly, it's higher among professionals than learners. Maybe that's because learners are going to be using some of those newer AI-adjacent editors, or because learners are less likely to be using Windows at all.
I'm sure people will leap to the defense of their chosen text editor, like they always do. "Oh, they separated vim and Neovim! Those are basically the same! I can combine those, really, to get a better score!" But I think a better takeaway is that it's incredible that Notepad++, an open source application exclusive to Windows that has had, basically, a single developer over the course of 22 years, has managed to reach such a widespread audience. Especially when Scintilla's other related editors (SciTE, EditPlus) essentially don't rate.
I think the argument you made for combining vim and neovim is pretty good actually. But it seems pretty unique to those two editors (well, throw vi in there if it ever shows up on the chart), so “worst” case notepad++ would be bumped down just one spot.
If vim were good enough, neovim wouldn't exist. If neovim were that much better, vim wouldn't still be as popular as it is. And if neither of them did anything worth picking up, then vi would still outrank them.
The conclusion is that they don't do the same things. They just both have the vi interface. But having a vi interface isn't particularly weird anymore. SublimeText and vscode have vi bindings. So does PyCharm/IntelliJ. So does Notepad++! Heck, so does nano! So who gets to claim those editors? Vscode is the most popular editor that supports a vi-like interface. Shouldn't that mean that vscode is the best of the "vi descendants"? Or does it mean that all these people were okay with the vi interface, but had a good reason not to make the choice they did for another editor?
Fundamentally, the issue is: Either choice matters, or popularity doesn't matter. You can't have it both ways.
>Maybe that's because learners are going to be using some of those newer AI-adjacent editors, or because learners are less likely to be using Windows at all.
You can use the 2022 (ie. pre-chatgpt) results for control for that. The results are basically the same.
Supply chain attacks have impact on more systems, so it's more likely that your system is one of it. Opening a poisoned textfile that contains a exploit that attacks your text editor and fits exactly to your version is a rare event compared to automatically contacting a server to ask for a executable to execute without asking you.
Those games did weird things. Every distro still ships SDL1, x11 didn’t really break API, and requiring a specific driver is obviously broken from the start. I won’t say none of this happens but the platform isn’t to blame there.
I never understood why glibc needs to break ABI. It should not be allowed to. Ever.
You are not reinventing the wheel. Just maintain the damn thing and keep it running as is. As Linus once said "If there's a bug that people rely on, it's not a bug, it's a feature.".
It makes zero sense for traditional distros to have payments. They exclusively repackage software. You want direct to customer platforms (Snap, Flathub, etc).
I don’t remember ever having to activate a piece of RedHat code after downloading it. I do remember paying a subscription to have authentication to particular repos. It’s been a while, though.
I'd have a very good hit rate, it mostly comes down to knowledge of toolkits. There are native apps that use their own toolkit, mostly written in Rust these days, and they always are worse than traditional toolkits (accessibility, respecting platform settings, visually fitting in, etc). That same issue applies to webapps typically.
The way keyboard-only usage works, if it is workable at all, is usually a dead giveaway. As is the lack of dialog windows and traditional menus, and often latency.
reply