I’d argue that the more popular models are a significantly higher risk. To exempt these from the rules doesn’t really make sense. A single malicious update from someone with unauthorized access (or even the owner themselves) will do significantly more damage if the model is popular.
That said, granular permissions are a much better idea, but I’m personally willing to accept complete blockage of these features in the meantime if it means granular permissions are guaranteed.
The legacy private model like systems can still use loadstring based insertion methods, like sharing a .rbxm file which then loads it dynamically from a website. So thats the fix for the ro-services that require obfuscation.
Does this mean that free models will be unable to require anything or can we still use it for ModuleScripts? If we can’t require ModuleScripts then I can see a LOT of tools breaking.
Decent update though, even though I think the scripts should not be limited, I see this will do more good than harm.
These modules shouldn’t do this, though. Dependencies that automatically update without your knowledge are always, always, always a terrible idea. It doesn’t matter who made it or how reputable the resource is, you should be the one updating your dependencies. Provide a prompt that the module is out-of-date, sure, but do not automatically update it without me knowing.
It seems like what you want is better version control tools for dependencies, and I think everyone should be for that. However, having your dependencies update behind the scenes is dangerous and opens the door to so many vulnerabilities.
The maintainer of DS2 has spoken out about this exact thing and why it’s bad. Additionally, they said they’re bad at remembering to update the marketplace version of the module, which means you’re more likely to be running an outdated version even if you require by asset ID!
Bad news is that the require check is fully spoofable by malicious models, they can simply just do something like this
local k1 = {"C" = function() return 5342534 end}
local scriptData = function()
return {
Hi = "K",
L = k1
}
end
local function closure1(yes)
return {
yes,
{
WaitForChild = scriptData().L.C
},
"Hello"
}
end
yes, script, thing = unpack(closure1(5))
local require(script:WaitForChild("ModuleScript"))
The only real way to prevent this issue is allowing us to block 3rd party requires all torgether
THIS!!! As much as the popular models and the people behind it do God’s work, this only puts those who maintain it in a very dangerous spot. While versioning is a thing for models, once someone gets access to the whitelisted item, nothing would stop them from hiding a require function and spam the publish version to cause some damage.
We would’ve been better off either blocking require requests or more time to figure out an alternative to this problem rather than just burn the marketplace down.
that is true. This can cause code to break, dependencies shouldn’t do this. But casual models, like admin command models, car models, etc auto updating isn’t that big of a deal. Not to mention, auto updating can automatically fix bugs across games. Which is good for people using the models, and the developer as it lowers the probability of bad ratings on the model.
To answer your question, no. This update will not affect your ability to require ModuleScripts directly.
Again, good changes, but this is going to cause me huge issues with checking for updates, as well as many other developers
Myself, and many other developers rely on external modules to check plugin versions, and I’m now going to have to update my plugins to not rely on these modules. Furthermore, the only solution as far as I’m aware (apart from using HTTP requests), uses a lot more data than modules, sure it’s minimal being around 300kb instead of 3kb or so, but still it’s not a change I’m happy about.
this is yet another bandaid fix, on the expense of everyone.
although i don’t really care in the end because i do everything myself, you could alternatively just assign “can use ‘require’” variable in scripts, alongside “disabled”
A step in the right direction I guess? You’re killing the weed at the top though, you need to get to the root of the problem, and that is the viruses themselves. Specifically the ones with inappropriate content that get developers auto-terminated. Third-party requires and getfenv/setfenv wouldn’t really be too much of a problem if rule-breaking assets were terminated rather than innocent developers. I will admit that obfuscation has no point on the platform though, so good work.
There is so many better ways you could’ve gone around this Roblox why did you not ask the community before just acting. You need to think about the community and not just yourself!
It doesn’t matter what the dependency is, automatically updating is dangerous. What happens if the owner of Adonis gets compromised and a malicious update is pushed to the model? Suddenly, thousands of games have a backdoor that is free to abuse until it’s removed. If a developer has more sinister intentions they could keep a backdoor there once the model gains a following and abuse games that may not be updated anymore.
Granted, there are upsides to automatic updates, but they do not outweigh the risks. If you want to keep on top of the updates for a dependency you use then you should follow it in the appropriate channels (DevForum, GitHub, Discord, etc) and petition Roblox to provide better versioning tools for public models.
They already do terminate malicious models. Besides the “root of the problem” isn’t the malicious models per say, (there isn’t any fool proof thing to fix this), but the fact that features like 3rd party requires exist and there doesn’t exist any very god ways to contain them.
Doing something about potentially malicious features to contain them is a much better approach (and has been proven to be the most effective with fighting malicious scripts, examples include 3rd party sales and teleport restrictions, and plugin permissions.)
But yeah I do think this change was made too quickly, they should have given a 4-5 month period at minimum to migrate, this currently is made too quickly so people can’t migarete their systems in time.
Many old projects depend on requires and fenvs so its too short of a timeline for migration, more time should be allowed.
well, this does help others from falling victim of false account deletions (which happened to my main ive had since 2013) (and also my dev fourm acc still exists somehow)
i was really hoping to make my own admin panel script, but this prevents development entirely for everyone. i cant even make an autoupdate in my scripts anymore. please revert the update, and instead LISTEN to the community and allow us to OPT OUT of requires. we should NOT all be punished over a small part of our community behaving badly. this entirely kills off organized scripts, and smaller admin panels. (we can live without getfenv)
the biggest giveaway to a bad module is a module called “luaparser” or “loadstring” so people can exploit on infected games. and they always use “rerubi” or something along the lines of that. theres many solutions you could have chose, and were open in the air yet you chose the worst one possible to do. revert this update immediately, you know it says something when even the owner of HD admin does not think this is a good change
also we need a moderation overhaul, i provided proof in my appeal and yet i did not get my account back. which is infuriating since ive had my account since i was 4 years old. and its all gone! i was looking forward to having my acc become 10 years old but thats not happening anymore i guess, thanks for listening to the community roblox devs.
Yes, I didn’t think of this, and I agree, But using httpservice for auto updating isn’t very much of a solution. As many games dont allow httprequests. And as of now, there is no api for auto update tools. The only way to have this functionality without httpservice is module scripts.
Sorry, I’m confused about how HTTPService fits in here. Automatic updates shouldn’t be a thing, period.
Auto updates should be able to opt out of not removed entirely they are a really useful feature for some things
Many games don’t allow web requests specifically for the reason you’re arguing against. You should NOT be doing anything that would affect another person’s game. What if one of your bugfix updates breaks a large game that uses your module? Are you going to pay for their losses? You likely claim no liability but require that your users rely on your updates. If the version is out of date, you can notify the developer and they can manually update. This is the way everyone in the real world does it.