Closed RayBytes closed 1 year ago
TODO:
Alright I didnt find a way to properly make pre 1.7 work in the normal profile, so here is the aptley named "Pre 1.6 Patcher". If you need pre 1.6 you would use this, otherwise you're fine.
Would basically use this as: python patcher.py /Path/To/Sandbox/File.sb
import sys
import os
sandbox_file = sys.argv[1]
if os.path.isfile(sandbox_file) & sandbox_file.endswith('.sb'):
with open(sandbox_file, 'r') as file:
data = file.readlines()
for line in data:
if "$HOME" in line:
data[data.index(line)] = line.replace("$HOME", str(os.getenv("HOME")))
with open(sandbox_file, 'w') as file:
file.writelines( data )
else:
raise FileNotFoundError("Sorry, no sandbox file was found at your given file directory. ")
All it really does is replace the $HOME environment variables with the users actual directory, /Users/username.
Because it would be annoying for every user to have to run this command for the profile to work, and I would like to have the least tech solution as possible for 90% of people, and pre 1.6 people are likely a minority.
i would like to note sandbox-exec
is deprecated. please see this bazel issue, as well as this post on the swift forums; i don't think implementing this is a viable long term solution due to this deprecation. a better alternative imo would be following apple's guidance and using their entitlements system
i would like to note
sandbox-exec
is deprecated. please see this bazel issue, as well as this post on the swift forums; i don't think implementing this is a viable long term solution due to this deprecation. a better alternative imo would be following apple's guidance and using their entitlements system
sandbox-exec has been deprecated since 2020, however it has still being used in system for quite some time. You can see a full list in /Library/Profiles I think. sandbox-exec is also still the backend for the App Sandbox feature in xcode, and theres no sight of it being removed any time soon.
however it has still being used in system for quite some time
this doesn't mean it will continue to be, nor that we should start using it now. this is what deprecation is supposed to mean: not removed, but unsupported/not recommended.
sandbox-exec is also still the backend for the App Sandbox feature in xcode
so why not use intended frontend? i also can't find any sources on this, and logically i don't see why they would be using sandbox-exec
directly and not bsd's sandbox
, as the former is meant to be a user facing cli component. futhermore, using entitlements directly would make for a much easier experience in launcher's upstreaming this, as it can be directly integrated with projects as opposed to users being required to launch clients from the cli
however it has still being used in system for quite some time
this doesn't mean it will continue to be, nor that we should start using it now. this is what deprecation is supposed to mean: not removed, but unsupported/not recommended.
sandbox-exec is also still the backend for the App Sandbox feature in xcode
so why not use intended frontend? i also can't find any sources on this, and logically i don't see why they would be using
sandbox-exec
directly and not bsd'ssandbox
, as the former is meant to be a user facing cli component. futhermore, using entitlements directly would make for a much easier experience in launcher's upstreaming this, as it can be directly integrated with projects as opposed to users being required to launch clients from the cli
the bazel issue which you had talked about, the person who was assigned to the issue also had written this post: https://jmmv.dev/2019/11/macos-sandbox-exec.html. Thats where I had gotten the idea of sandbox-exec being the backend of the app sandboxing too. Regardless, I am pretty sure App Sandbox feature in X Code cannot be applied to minecraft itself, because the language macos apps are written in is with Swift/Obj-C, and I'm pretty sure XCode does not support anything else.
Also, in comment to your first part, the fact that it is still in system means that even if it does get removed from the user side, it will still be necessary on the system side, meaning it will still be there, but could be even less documented that it already is, which isn't much.
Also, it is already possible to allow other clients to upstream it. Other launchers just need to give access to their own data, and from wherein they launch the app.
Actually looking into it, it may be possible to bundle Java Apps to upload to the mac app store but I do not think you can actually put java into your XCode. Some people have said its possible to do a little bit of weirdness with obj-c and build a layer around java, but it does not seem like the cleanest solution.
Chrome and Firefox and Apple's bazel are also currently using this tool, so I do not think Apple will suddenly be making it fully disappear without any replacement
Regardless, I am pretty sure App Sandbox feature in X Code cannot be applied to minecraft itself, because the language macos apps are written in is with Swift/Obj-C, and I'm pretty sure XCode does not support anything else.
this wouldn't be needed if you sandbox the launcher itself, which is easy to do with entitlements given that those are still enforced in child processes.
I do not think Apple will suddenly be making it fully disappear
of course not, it's only deprecated
without any replacement
Regardless, I am pretty sure App Sandbox feature in X Code cannot be applied to minecraft itself, because the language macos apps are written in is with Swift/Obj-C, and I'm pretty sure XCode does not support anything else.
this wouldn't be needed if you sandbox the launcher itself, which is easy to do with entitlements given that those are still enforced in child processes.
I do not think Apple will suddenly be making it fully disappear
of course not, it's only deprecated
without any replacement
Once again, how are you going to do this on the launcher since this can only be done in Xcode
Once again, how are you going to do this on the launcher since this can only be done in Xcode
because it doesn't need xcode? only an entitlements file. prism already has one for example and it's packaged with the app here
there is also a more hardened version here in the discord server
Interesting, Apple docs only talk about through XCode, which I guess is understandable. Also I can't see how you restrict the actual file system in this entitlements system.
The point of the sandbox is to restrict the file system to only necessary components and libraries
Looking a bit more into it, it is possible to give access to certain files in the Container. Though I still do not honestly see the benefit of this entitlement system over the profile system. It just seems to be the profile system migrated into XML
Also, wouldn't this entitelement file need to be in the binary of the actual app? How is this going to work with the vanilla launcher? Will we just need to add a file to the minecraft library folder?
Prism launcher has now also been tested, 3 changes had to be made for support, but now it works. Profile should work for all launchers as long as they do not require different files/resources from the system than the base game.
This pull is now ready @xyzeva. I've basically done most of the stuff I wanted to do. More pulls will likely just be with more launcher support and more tools added to the patcher for launcher devs and users (along with making the code good).
BTW any MacOS users - please go test the files in this pull.
Actually, wait. I have an idea to completely eliminate the patcher.
Alright done
This is just a draft pull I will keep updating as I now enter beta testing for this profile, as its now entered the stage where it can be used publicly.
If ya'll want to test it out just get the file either from my repo or just look at the changes in this draft pull.