Sleazy Fork

Some thoughts on library scripts

Hi,

I have some thougths about the actual implementation of libraries on greasyfork and some problems which can occur at the moment. I'd like to share my thoughts with you and hear your opinion on them.

If you provide a library which is required by many scripts, every change to this library leads to changes in every script which requires this library. This causes a problem if you don't include a special version of the script, but the latest release and the change in the library is malicious. With the next update of the script, this change is included in your script and your is also malicious.
A few years ago, this happend to a script library which was included in many userscripts for the browsergame Ikariam. The userscripts.org account of the developer was hacked and some code was inserted which destroyed player accounts. To revert these changes, more than 100 game servers worldwide needed a backup.

What is my solution to prevent this?
Don't allow the installation of the latest version, but the developer has to refer to a specified version of the library in order to prevent malicious changes in the library to be distributed to all scripts. With this change the devloper of a library has to change the included version manually and changes in the library are also visible to the code of the scripts that include this library.

Another benefit would be the preventation of broken scripts if a script is not maintained anymore and the included library needs to change the API. Even if you should not change the API of a library in a way which is not compatible with the old API, sometimes this change is necessary (or just done by the library developer). Any script which is not maintained anymore is broken from this moment even if it would be possible to use the script with an old library version - assuming the newest library version is automatically included.

Another (small) suggestion I'd have for the library site is a text field to copy the require path for the library. At the moment there is no install button at the normal page (I know its intended), but at the version page so you have to switch to the version page or built the path from your knowledge of the uri structure. If you want to include the newest version as specified uri, not as general uri, this is a little bit long-winded. So my suggestion would be a text field with the specified link to the newest version on the main page of the library (according to my suggestion above, that there is no general linking of libraries possible). I'd say, this would be an enhancement for anyone who wants to use the library.

Regards,
Tobbe

These are valid concerns when using user-provided scripts, but the concerns are covered in other ways that you've suggested. Any author concerned about a required script changing can get a specific version uploaded to the site in https://greasyfork.org/libraries/ . Essentially, the require-from-another-script-entry option should be the last resort, and I don't want to add additional restrictions on it.

Adding a suggestion to use a particular version (with the URL to use) is a good idea though. I've filed it as https://github.com/JasonBarnabe/greasyfork/issues/80

Essentially, the require-from-another-script-entry option should be the last resort

This might be the case if the script is uploaded as a normal userscript, but as far as I understand, libraries must be required ;) So my suggestion was only for the libraries, not the "normal" userscripts.

Another possibility might be to let the library author decide whether he wants to allow the installation of the latest version without specifying a revision or only allow the installation of a specified revision. There would be a checkbox when creating a new library script and if it is checked the /script/123/code.user.js will return an empty page if you don't provide the specific revision you want to retrieve. The decision would be up to the library author and you don't force them to use this restricitions.

I think it's sufficient just to suggest to people that they use a specific version of the script rather than forcing them to. At some point, authors need to think for themselves about these issues.