This mods tries to add a less trusted kind of mods than those in secure.trusted_mods. But these new kind of semi-trusted mods are still allowed to use require. With this they have practically the same priviledge level as usual trusted mods.
If you want to provide a more secure way of require, you can make this wrapped require available in the insecure env, so other trusted mods can use it.
Also, there are several things broken with the implementation (many unfixable without engine support). Obvious things: Other mods can simply overwrite settings that don't start with secure.. They can also overwrite other things (and therefore hook into), such as core.settings, core.get_current_modname (note also that this mod might not be the first to be loaded), or your unsafe_require API function. And another mod could your mod make call one of its functions, so core.get_current_modname will never be correct (this is also why core.request_insecure_environment can only be called directly from the mod's init.lua).
This mods tries to add a less trusted kind of mods than those in
secure.trusted_mods. But these new kind of semi-trusted mods are still allowed to userequire. With this they have practically the same priviledge level as usual trusted mods.If you want to provide a more secure way of require, you can make this wrapped
requireavailable in the insecure env, so other trusted mods can use it.Also, there are several things broken with the implementation (many unfixable without engine support). Obvious things: Other mods can simply overwrite settings that don't start with
secure.. They can also overwrite other things (and therefore hook into), such ascore.settings,core.get_current_modname(note also that this mod might not be the first to be loaded), or yourunsafe_requireAPI function. And another mod could your mod make call one of its functions, socore.get_current_modnamewill never be correct (this is also whycore.request_insecure_environmentcan only be called directly from the mod's init.lua).