Why the mod injector is loaded by reflect?
Closed this issue · 2 comments
This whole "Bootstrap" thing is part of my naive approach for supporting Fabric Load 0.12+ back in 2021. The key is this line:
IIRC since 0.12.x Fabric Loader load its internal classes in a ClassLoader separate to the one the game and mods are using. Thus in order to inject into, or even just get access to, Fabric Loader's internal classes, as it's done in ModInjector.install() and DirectoryWalker.walk(), we have to load our relevent code with Fabric's ClassLoader.
This worked under development environment when tested back then, but since the official releases of Fabric Loader jars are digitally signed this is not usable in real situations.
WARNING: Groundless rants ahead; contact me for deletion if you feel offended.
(To Fabric Loader developers: Just WHY?? Why are you actively locking your packages down, which doesn't serve any praticial purpose other than messing with us mod developers? Like, it's not justifiable even for security reasons; you're running an open-source project to inject unsigned 3rd-party code into a game, and there's no point trying to play nice. If you're really into security, might as well obfuscate all of your internal classes so as to ensure no bad-behaving mods like the one I'm making here could ever exist. Heck, why not just require all mods to be signed by you and host a marketplace for them? That's some MCBE Marketplace BS all over again. Oh wait, maybe we can just write a wrapper to chain-load the Fabric Loader and bypass the lockdown? Don't worry, the developers got you covered: Fabric Loader's entrypoint is an implementation detail. There's no escape. Frankly, now I kinda understand why Quilt is a thing.)
Closing as it's not an issue.