Blockland Glass Mod Manager [Released!]

[Scout31]

That's extremely weird. Maybe one of us decided to reject it, and the system lost track of something? And now it appears that 5 of us approved it. I'm gonna go pull the raw data and take a look.

[Ad Bot]

[jes00]

Site is back up.  It looks like there was a file that had 4/4 approvals but was still considered "unapproved" for some reason.  When I hit approve again this issue was corrected.  The file in question is http://blocklandglass.com/addon.php?id=35

Actually I just checked back and again it said 4/4, pending approval.  I clicked approve again and this time it looks like it is fixed for good.

Yeah, if you look at the news it appears that mod has been approved 3 times.

It wasn't approved when I looked.
I approved it too and it appears to have gone through.

FLUDD however has 4 approvals and yet hasn't gone through.

[Nexus]

It wasn't approved when I looked.
I approved it too and it appears to have gone through.

FLUDD however has 4 approvals and yet hasn't gone through.

That's probably because it was rejected by 3/4 people, did you read the feedback?

[jes00]

That's probably because it was rejected by 3/4 people, did you read the feedback?

Woops. Didn't see it.

[Scout31]

Yeah, it's somehow reverting back after a few minutes. The raw data seems completely fine.. I'm not sure what script would run on its own moments later that would un-approve the add-on.

FLUDD however has 4 approvals and yet hasn't gone through.

Yeah, any red-shirt is a rejection.

Edit: found the problem! Part of the old implementation of upstream repositories is still active, and Server Events has been updated since I rewrote the code, essentially breaking half of the upstream system. At this point, it's resetting the file data and scanning the new file, but not updating it. I believe this may also tie in with the SemVer issues I mentioned earlier.

[Scout31]

Reviewers, you should now have the option to Bargain bin an item.

Rule of thumb until I can type up something official.

Approval is for add-ons that are high in quality, both in terms of code and user-end

Bargain is for add-ons that are either generally bad and dysfunctional, or have some sketchy (but not explicitly dangerous) code, such as what we saw with someone using eval way too often. It wasn't dangerous, but it was just generally bad practice.

Reject goes for any add-on that has clear malicious code.

For flat-out broken or incredibly inappropriate add-ons, there'll be a system to handle that. It'll be a one-click button press that doesn't require collaboration.

[Nexus]

Can we retroactively vote to put things in the bargain bin, such as prints with no screenshots?

[Ipquarx]

I'd like to point out that code doesn't have to explicitly allow remote code execution to be malicious; One addon could define a "harmless" client-side only function that uses eval, and then another seperate addon by a different author (colluding with the previous one) could code it using that seperate addons function in such a way that it may allow for code injection via TCP or through using the function in a servercmd while still looking completely harmless.

[Nexus]

I'd like to point out that code doesn't have to explicitly allow remote code execution to be malicious; One addon could define a "harmless" client-side only function that uses eval, and then another seperate addon by a different author (colluding with the previous one) could code it using that seperate addons function in such a way that it may allow for code injection via TCP or through using the function in a servercmd while still looking completely harmless.

The idea is any code that is able to abuse another client mod in a malicious way is just as capable of having the malicious code itself.  The main difference there is obfuscation, of course.

[Ipquarx]

The idea is any code that is able to abuse another client mod in a malicious way is just as capable of having the malicious code itself.  The main difference there is obfuscation, of course.

Yes, which can make it extremely hard to detect, especially if they're released with any large span of time inbetween.

I'd like to make quite a big statement here: Eval is never necessary. Setting arbitrary variables can already be done without eval. Running a piece of code after a specified time or as a callback can always be done through functions (Those are the two most common instances of eval I've seen). Therefore, any script that has even a client-sided eval injection should denied and the reviewer should guide the uploader through safely replacing the function.

[Scout31]

The only practical use of Eval I can think of is callback functions

Can we retroactively vote to put things in the bargain bin, such as prints with no screenshots?

Yeah, I'm just thinking of how would be the best way to do this.

[jes00]

You should have the option of adding prints while you're submitting your add-on.

Reviewers should be given the ability to move add-ons to a different category.

[Zeblote]

I'd like to make quite a big statement here: Eval is never necessary.

It is, if you need to dynamically make functions or datablocks. For example allowing the host to change a /command via preferences and similar things.

[Scout31]

Reviewers, you should find a new control panel/system for approving add-ons.

[jes00]

Reviewers, you should find a new control panel/system for approving add-ons.

Code: [Select]

Not Found

The requested URL /mod/reviewer.php was not found on this server.

Apache/2.4.7 (Ubuntu) Server at blocklandglass.com Port 80

You should also probably make the apply for reviewer thing not appear for reviewers.