BAM Development (see page 25)

[Port]

Here's a mockup for the possible appearance of server control.

[Ad Bot]

[blueblur121]

Wait. Is that a server hosting service? How much will it cost?

[Subpixel]

Wait. Is that a server hosting service? How much will it cost?

I think/hope it's the in-game options.

[Truce]

On add-on reviewing, neither human checking nor scanning will ever be perfect. You have already addressed scanning's issues.

http://pastebin.com/n4exjEky

That script (on RTB here) contains code to access the server's console remotely. I believe this was at a point where RTB had its mod review staff. Despite being a massive exploit, it slipped past because humans are not perfect. To save you pointless work, you're probably going to want to take after the add-ons forum where things can just be posted and removed at a later date. Your comments about alerting users of when their add-ons are failed is certainly a good idea, but perfecting prevention is probably not worth the effort.

[Port]

On add-on reviewing, neither human checking nor scanning will ever be perfect. You have already addressed scanning's issues.

http://pastebin.com/n4exjEky

That script (on RTB here) contains code to access the server's console remotely. I believe this was at a point where RTB had its mod review staff. Despite being a massive exploit, it slipped past because humans are not perfect. To save you pointless work, you're probably going to want to take after the add-ons forum where things can just be posted and removed at a later date. Your comments about alerting users of when their add-ons are failed is certainly a good idea, but perfecting prevention is probably not worth the effort.

That code would trigger the "suspicious" list available here with a clear warning of every line it occurs on to reviewers. It would be failed due to not escaping content passed to eval(), and unnecessary use of raw eval(). Most of those could be replaced with expandEscape("\\c" @ ...).

[Truce]

That code would trigger the "suspicious" list available here with a clear warning of every line it occurs on to reviewers. It would be failed due to not escaping content passed to eval(), and unnecessary use of raw eval(). Most of those could be replaced with expandEscape("\\c" @ ...).

You want to fail add-ons due to not being efficient? That seems awfully ignorant towards new coders.

[Zeblote]

http://pastebin.com/n4exjEky

What the hell is that

That code would trigger the "suspicious" list available here

Why these?

Usage of secureCommandToClient()
Usage of secureCommandToAll()
Usage of secureCommandToAllExcept()

I though you couldn't use those anyways?

[Port]

You want to fail add-ons due to not being efficient? That seems awfully ignorant towards new coders.

Not because they aren't efficient, but because they're a security risk. New coders wouldn't know how to use eval regardless.

[Truce]

What the hell is that

That's what caused my key to get deactivated for remotely accessing consoles a few years ago, but the add-on was never found out since it was hidden. And even though it required users to download the add-on, which seems like it would limit servers, as it is an RTB add-on, you could use RTB's API to return a list of servers containing that add-on. The main intention of that API was to preview what add-ons were in a server before joining it, so obviously there wasn't a problem with that.

Not because they aren't efficient, but because they're a security risk. New coders wouldn't know how to use eval regardless.

Ephialtes is clearly a successful coder and ran RTB for a long time. See what worked and improve it.

You're not going to get anywhere if you have shame in learning and feel the need to invent everything.

[Ipquarx]

The reason we're thinking of ways of approving the system is exactly that: it didn't work very well for rtb.

Now, just because an addon gets flagged because it uses a dangerous function doesn't mean it's an exploit no, but since in our system it would be reviewed by extremely competent users, things like that won't get through the cracks, since there are none. An addon like that would be failed because of insecure use of eval.

Put it this way: we're remaking the wheel because it got repeatedly shot at by a minigun.

[Rub]

It worked fine for RTB, the main issue was the lack of people willing to commit their time to trawl through all the bullstuff submissions you get - trust me, you won't be prepared for this.

You should really focus less time on approving addons and the mechanics behind it and more on features the community is going to benefit from.

[jes00]

It worked fine for RTB, the main issue was the lack of people willing to commit their time to trawl through all the bullstuff submissions you get - trust me, you won't be prepared for this.

You should really focus less time on approving addons and the mechanics behind it and more on features the community is going to benefit from.

I'd be willing to review add-ons.

[Port]

I can't tell if this style is too different or not.

I'd be willing to review add-ons.

We're going to be accepting a moderately large team of general reviewers - they can see pending submission/update "pull request" pages, comment on them, etc. as well as a small, very close team of privileged reviewers which are the only ones with the ability to actually approve or disapprove an add-on.

[Lugnut]

You want to fail add-ons due to not being efficient? That seems awfully ignorant towards new coders.

We're going to fail add-ons if they extremely dangerous functions improperly.
We'll probably give them a link to a topic about eval injection or something if someone gets around to making one.

What the hell is that
Why these?I though you couldn't use those anyways?

The fact that they're trying is suspicious enough. fileDelete is not necessarily a bad thing, but attention needs to be directed towards it.

It worked fine for RTB, the main issue was the lack of people willing to commit their time to trawl through all the bullstuff submissions you get - trust me, you won't be prepared for this.

I can see this. However, you've got to understand that we're going to have a lot of reviewers.
The idea is this will reduce the load on the 'privileged' reviewers, which is a smaller group.

[blueblur121]

The more reviewers you have, the bigger the chance that one is not doing his job correctly. While in theory this sounds like a great idea, it has the potential to have a lot of cracks in the system.