I believe that a modified combination of the two would be a perfect balance. What I mean is, uploaded files are able to be downloaded instantly, but are boldly marked as “unsafe” until they are reviewed by a staff member. This would enable the community to decide who is trusted in the community and who isn’t, making it fast and secure.
EDIT: Also, it might not be a bad idea to add a “trust” value to each member of the plugin development community. For every file that is reviewed and found to be “safe”, the plugin’s developer earns a trust point and vice versa.
While there may be collisions, I think it would be highly unfathomably improbably for someone to actually code a malicious plugin that has the exact same MD5 Hash as a genuine plugin. Please provide some examples if I’m off-base with this assumption.
I was about to suggest the same thing. A package manager (such as aptitutde, yum, npm, choco, brew etc) poiting to official repos could also help as the next step in the submission and evaluation process. Tested, approved and
“safe” releases can very well be the ones that make it to the official repo, so end users have a very solid and trustworthy (not to mention easy and automated) way to install and manage plugins.
Just imagine writting in the console: /soak install mcmmo , and 2 minutes later your serve has mcmmo installed and running… or /scrub update essentials , and you update to the latest stable build (obviously soak and scrub are just two names on the top of my head for a potential package manager).
I do realize that his might be outside the scope of Sponge, but I’m throwing it in as well.
MD5 may not be secure for data safety, but that’s not what we’re trying to do. We’re not using the scheme to secure anything, we’re just using it to confirm that the packages we’re installing are the packages we mean to install, and that they’re not corrupt.
Collisions, in this case, while possible, aren’t really an issue.
we’re just using it to confirm that the packages we’re installing are the packages we mean to install, and that they’re not corrupt
are the same thing. Verifying that the thing you’re trying to install is the thing you asked for and that it hasn’t been tampered with are inherently the same problem.
There have been research groups who have engineered passwords that collided. There isn’t really much of a difference between that and creating an archive with the same checksum as an earlier one, especially considering the peculiarities of the Zip format (can contain an arbitrary amount of scrap data, as long as it’s not referenced by the end-of-file header, for example).
When I said that the scheme wasn’t being used to secure something, I may have been a bit more general than I intended. Whereas you may not want to use MD5 as the sole method of securing a password, it’s much less of an issue with differentiating between files.
Collisions isn’t something we’re worrying about because, as @pale said already, the possibility of a malicious plugin having the same Hash as a genuine one is very slim. Even more unlikely is that the malicious plugin would match the Hash of a relevant genuine plugin.
The solution here is to not use MD5. SHA256 hashes would adequate, dont add that much computational power over other hashes, and and are just twice the storage requirements of a MD5 hash (64 chars vs 32 chars).
I personally would like a repo type system. More of a community based thing with ratings, and reviews. Certain repos are run by different set of users. You can add or remove a repo within the sponge environment, etc. Then you can choose from the repo, look at the ratings and such. Repos could do automatic updates, or some sort of plugin verification, etc. Each repo can have it’s own way it operates.
Do we really need hash checking, surely if somebody is in the position that they could modify the files on the sponge servers, then they would be able to change the hashes stored, or is that not the case?
Or they could be extra sure, and use SHA3-512 Hashes. Less clashes, so you can be absolutely sure, and I mean if you really want who says you can’t compress it with say Snappy or something?
Plain hashing? Not much of a point. However, there is a good point to signing the plugins, since that means they can be verified against a local master certificate which would prevent unauthorized tampering (or at least help protect against it).