Anyways for people that use this encrypt API, someone has made an open source Encryption API that has simullar functionality Lua AES Implementation
That’s not really the point. The point is that people that had a game working fine will have to find a new method to encrypt and have to spend time changing their game code. They might even not know its my encrypt api being offline causing the issue meaning they will need to spend hours debugging. They could have also been saving encrypted data now all that data will be useless.
1 Like
This really doesn’t seem like the best idea, there should just be a setting to disable require() globally in our projects instead of a marketplace wide ban as this will definitely break a lot of things 
2 Likes
You’re missing the point here… Look what happened to node-ipc!
Imagine if this was auto updated!
Roblox should follow suit with every other package manager and add semantic versioning, hence why Wally exists.
1 Like
From the wording of the post, it seems that the only thing this announcement will impact is toolbox visibility for models that use getfenv, setfenv, or require on third party modules. The “will no longer be allowed in assets shared in the Creator Marketplace” wording implies that this won’t actually cause your code to break, it just won’t appear in the library if it is public.
Edit: I guess this could also mean that any models set to public cannot use those APIs at all, in which case I would just make your model private since you aren’t widely distributing it… but I find it hard to believe they would completely ban all models like this instead of just hiding them from the toolbox.
2 Likes
I’m not developing anything on roblox anymore (like a big break) but I feel I have to share my perspective on this update. I’m glad to see you are trying to solve these problems of viruses, backdoor and more. I had actually developed a plugin for analising assets to deal with this problem before. When I was developing the plugin, I didn’t want to do what others do, automatically delete everything that was looking suspicious. Instead, I decided to display a list to the user to let him determine by himself what he wanted to do. In the same context, I think that preventing the publication of scripts containing getfenv/setfenv, require or “Obfuscated code” is counter-conductive for some. Now I’m not saying that this is a useless idea, it will clearly improve the situation, as everyone knows how infected the marketplace is with these scripts. But I personally think that this is not the right way. You could for example display a warning to the user that the script he wants to add from the toolbox is suspicious. This would allow all developers to continue to use and share scripts containing these useful functions while warning them to check the script to be sure. As for the “Obfuscated code” I agree that an obfuscated script does not inspire trust and cannot be verified manually with ease. However, I wonder how effective you are at automatically detecting an obfuscated script, what to do if it was a false detection? Will the user be able to fix the problem? Will there be any indication of the reason for the detection?
As others have said, there other solutions that i think you should implement too, i could take @metatablecatmaid for exemple, allowing the users to block require in the engine is a good solution. I would even say that it would be better to let the users decide what he want to allow and block himself. If he want to block requires, he block it, if he want to block modelescripts, well he block it too. That would be, i think, another good option to help fixing this issue with viruses and backdoor.
2 Likes
Local modulescripts pose little threat, besides they are used very very widely for legitimate purposes, nearly every game and model uses them. So it really doesnt make sense to even have a feature to block them.
2 Likes
This is true, and i am myself using them everywhere. This was mostlikely a exemple to make the point of “allowing the user to block functionality he want to” since i wasn’t having a lot of idea for the enumeration
Great, thanks for the heads up
2 Likes
I find it strange how you can be so sure of what the future holds or why I should trust automatic updates on a promise of some developers’ account security. I also find it strange how an admin system opens the opportunity for a game to be backdoored to begin with, but I digress. The point is that automatic updates are dangerous and leave no time for review.
@FxllenCode raises the great example of node-ipc. Now take the scenario of node-ipc and add automatic updates to the mix. You can trust a developer as much as you want, but at the end of the day, it’s not difficult to hide malicious intent online. Given the sketchy history of admin systems in the past, they’re literally the absolute last thing I want automatically updating in my game, lol.
8 Likes
Its normal for large code bases that have a lot of dynamic code to have some vulnerabilities. But Adonis has done a lot to prevent things like this, Adonis has fixed multiple vulns (some relating to LoadAsset while other relating to incorrent remote permission checks) and more, also Adonis is very secure on the server side to prevent tampering from malicious scripts.
This is not the solution we need. There are other solutions that are more viable that others have said here. This is very disappointing Roblox.
Exactly, whoever ‘owns’ the asset could get hacked, lets just say their account gets compromised and they don’t know it, then someone has access to update hundreds of thousands of games with one ‘trusted’ model.
This could be achieved through sandboxing and warning users of what services/permissions the application/plugin would like to use before being installed. Something similar to what we see in the App Store for example. I’ve written up a feature request for this in more detail here.
We see this as temporary (less than a year for example) as both Adonis and HD transition towards entirely new systems to overcome this. Applications like HD/Nanoblox and Adonis take literal years and tens-of-thousands of USD to develop though so its not something we can transition to overnight without impacting thousands of users.
9 Likes
Are players going to get moderated over this? I don’t want to wake up tomorrow seeing one of my accounts banned, over some non-malicious model that I released years ago.
I would hope that this merely prevents them from appearing in marketplace, or at the very least doesn’t punish uploaders of pre-existing models.
We got clarification on this; problem creations will simply be removed from search.
How so? Could all of the required modules not be included in each published model?
Require comes with very useful functionality, this update specifically targets public/on sale models & scripts(which is 3rd party scripts). You can no longer provide tools & services not managed by the game creator themselves. It feels like it defeats the entire point of having this feature. If it was by default disabled in-game or/and per script as a property that you change in Studio that would have been so much better in my opinion & have people be much more cautious about scripts, free assets & the feature altogether.
Roblox could also give the same warnings as models with scripts, or plugins that needs specific perms to scripts that needs require perms.
You know, I was hoping for a different approach, like I don’t know, allowing us to whitelist modules for require(id) in a setting like allowing http requests
This would have the same conclusion, but with some developer flexibility
1 Like
Yes, this would have had the effect of breaking auto updates until such time as the dev figures out how to whitelist it.
Allow us to block 3rd party modules from being required. I don’t believe it’s been said long enough, but we need it blocked completely with an option in game settings or by another method.
“But my 3rd party tool relies on requiring assets into the game with require(id)”
This seems like a developer issue. Assets should already be packaged into the main model itself for easier use.
“I use a framework that is auto updated via require(id)”
PackageLink solves this completely. PackageLInk allows for auto updating and permission based setup, meaning that if your game were to get stolen, people can’t use your packagelink without you granting access. Also comes with versioning and status tools built right in. Migrating your framework has never been easier, start doing some framework spring cleaning! (or summer cleaning)
There is no reason not to block 3rd party requires. They are usually not used for anything besides malicious activity.
1 Like