BAM Development (see page 25)

[Yin Yang]

Can't wait!

[Ad Bot]

[DontCare4Free]

..Or is it??

It isn't.

[vulnus]

Or or is it???

[Lugnut]

Or or is it???

enough. this thread is SRS BSNSS.
no but seriously, stop posting that crap before a chainban

[Lugnut]

is there anything we can do about the fact that the add-on is 1.3 MB in size? that's really loving huge.

i mean, RTB was 1.4, and I don't know what we can do... still worth keeping in mind, yeah?just had a long discussion with nullable. a bunch of ideas came up for BAM

Code: [Select]

* right after I posted this post *
teozkr (Nullable): eh
teozkr (Nullable): I'd still say anything below 50mb is a neglegible size :p
Lugnut: 1mbps internet doesn't play nice with 1.5MB add-ons in a game that usually has 1-3KiB scripts
Lugnut: and.. yes i just used 3 different units in one sentence
teozkr (Nullable): good point, but it's still a one-time download that would take about 12 seconds
teozkr (Nullable): and still pretty small compared to mods containing, say, models or audio
Lugnut: i guesssssss
Lugnut: oooooh
Lugnut: we should have a diff-based updating system
Lugnut: aahahahaha
Lugnut: that'd be cool and so loving unimportant
teozkr (Nullable): :P
teozkr (Nullable): yeah considering what it is for it'd be really cool (since you could piggyback on that for updating other add-ons as well)
Lugnut: it would work really well because scripts get updated more often than models and such, right?
Lugnut: quick easy updating
teozkr (Nullable): yeah
Lugnut: that actually /should/ be a thing
teozkr (Nullable): problem is in order to do delta updates you either need to write binary files or give up on compression
Lugnut: the only problem is we would need
Lugnut: yeaeh
Lugnut: exactly that
Lugnut: ironically
teozkr (Nullable): giving up on compression would also mean giving up on stuff like automagickally removing stale files
Lugnut: to save data transfer, we have to give up saving disk space
Lugnut: what do you mean by stale files
teozkr (Nullable): well, let's say MyAddOn v1 contains server.cs and impl.cs
teozkr (Nullable): in v2 impl.cs was renamed to implementation.cs
Lugnut: with a delta update, unless handled specifically, impl is still there
Lugnut: yes?
teozkr (Nullable): yeah
teozkr (Nullable): while with zips that would be done automatically
Lugnut: just a simple fileMove or something though
Lugnut: the delta system would have to be made manually
Lugnut: just add in support for moved files...
teozkr (Nullable): well yeah
Lugnut: probably more difficult than i'm thinking
teozkr (Nullable): or rather, add in support for removed files
teozkr (Nullable): since a rename is basically just a copy-and-delete
teozkr (Nullable): (same for moves)
Lugnut: i think you would need client side monitoring on the dev's side : if the file is moved, note that it was /moved/ not deleted and a new one was coincidentally made
teozkr (Nullable): well, explicit support for renaming would be an optimization
Lugnut: moved VS [deleted and a new one made]
teozkr (Nullable): not needed for v1
teozkr (Nullable): funny thing is that git actually already tracks stuff like that
Lugnut: stuff would still be cool though
teozkr (Nullable): yeah
Lugnut: does git work in binary or ascii?
Lugnut: can we backpack off of a git repo in torquescript????
teozkr (Nullable): git works in binary
Lugnut: now /that/ would be fun
Lugnut: damn
teozkr (Nullable): but you could have a proxy server that repacks it so torque can handle it
Lugnut: could we make an
Lugnut: yeah
Lugnut: external script in python or some stuff
teozkr (Nullable): like brickbucket :P
Lugnut: runs
Lugnut: idk
Lugnut: git log or whatever and sees the diffs
Lugnut: or even just
Lugnut: git diff > diff.txt
teozkr (Nullable): yeah
Lugnut: then have torquescript hadle everything else
Lugnut: we should probably have a build.sh file in the bam-addon
teozkr (Nullable): not sure how well bash scripts would work, considering how windows-centric blockland is in general
Lugnut: no on
Lugnut: no no
Lugnut: that would be on our side, the dev team of bam...
Lugnut: however
teozkr (Nullable): well yeah
Lugnut: for mass support for add-on devs
Lugnut: that would need more care...
Lugnut: wait
Lugnut: i think you already said this
teozkr (Nullable): but anything that could cause a higher barrier to participation in development would be a bad thing no?
Lugnut: what if when the developer uploads their new add-on
Lugnut: and we approve it
Lugnut: it gets processed like i said
Lugnut: they just have to pump in a new add-on
teozkr (Nullable): that could be done yeah
teozkr (Nullable): or even cooler, instead of uploading a zip file
teozkr (Nullable): just supply a git tag!
Lugnut: "higher barrier to participation"
Lugnut: requires use of git
Lugnut: i don't know very many TS only devs with git
teozkr (Nullable): I mean as an optional feature of course :p
Lugnut: only people I know of that use version control are people like you, me, port, brian smith, trinick, etc
teozkr (Nullable): or mercurial or whatever
Lugnut: we all know multiple languages
teozkr (Nullable): Slayer
teozkr (Nullable): BAM itself
Lugnut: interesting common denominator
Lugnut: yeah, but those are worked on by the more advanced group of devs
teozkr (Nullable): as I said, doesn't have to be mandatory
teozkr (Nullable): but could be a nice QoL feature for the people who actually use some sort of VCS
Lugnut: in that respect, yes, definitely yes
... about quality assurance...
Lugnut: anytime i see [an addon] that might be using eval() i get super loving nervous
teozkr (Nullable): eh
Lugnut: not because the devs are /malicious/ (although there seems to be a bunch of them nowadays) but because it's really hard to use eval right
teozkr (Nullable): on one hand I'm not too fond of any kind of manual QA, and it'd also require quite a bit of manpower
teozkr (Nullable): on the other hand, I'd suggest a blanket ban on anything calling eval or co :P
Lugnut: is there such a thing as automated?
Lugnut: i would say automated with really easy to trip detectors or something
teozkr (Nullable): yeah
Lugnut: like if it does just one thing that doesn't seem perfectly okay, put it up for human review
Lugnut: otherwise pass it
teozkr (Nullable): yeah
teozkr (Nullable): basically a security review
Lugnut: keeps the bar for human review above the "every single thing" level, but still allowing a lot of human interaction
teozkr (Nullable): but I don't really like when it turns into a quality review like RTB did (is the model pretty?)
Lugnut: furthermore, automatically passed add-ons should go in a big fat list
Lugnut: for review when a review team member is feeling bored
Lugnut: or something
Lugnut: but yes
teozkr (Nullable): hehe yeah
Lugnut: eval()
Lugnut: tcp objects
Lugnut: file*() commands
Lugnut: /anything/ that is just a little bit iffy
teozkr (Nullable): think there was a function_call or something as well
Lugnut: cal()
teozkr (Nullable): which is basically eval except less suck
Lugnut: call()
Lugnut: it's a clean
Lugnut: yeah
Lugnut: prevents eval injection or some dumb thing
teozkr (Nullable): but still dangerous
Lugnut: /that/ should be double checked
Lugnut: .... we should be writing these down... // so I did
teozkr (Nullable): http://bldocs.nullable.se/html/namespace_server_1_1_global.html#aff8f84aaa111abe1bb06a5cde5558164
Lugnut: we're not gonna sound the alarm whenever an add-on calls /any function on the default list/!!!
Lugnut: oh wait i'm a dumbass
teozkr (Nullable): :p
teozkr (Nullable): schedule as well
teozkr (Nullable): allows arbitrary code execution
Lugnut: stuff that /is/ a point for injection vulnerabilities, isn't it
Lugnut: should probably flat out deny any use of crash()
Lugnut: i don't know if it works
Lugnut: but even fi it doesn't it shouldn't be in someone's mod
teozkr (Nullable): it does
teozkr (Nullable): IMO, flat out deny both eval and crash
teozkr (Nullable): with eval causing a message about how call/schedule can be used instead
Lugnut: three lists nullable
Lugnut: a: automatically approved, for later review when someone is bored or something
Lugnut: b: tripped alarms. most activity from review team is here. called "call" or something
Lugnut: c: code red bullstuff - "eval" or "crash" usage. possibly consider banning user depending on severity
Lugnut: mod review team does work at b
Lugnut: administrative team does c
Lugnut: ... what if we allowed a to be public?
teozkr (Nullable): yeah
teozkr (Nullable): well
teozkr (Nullable): wouldn't a just be anything that isn't on b or c?
Lugnut: yeah
Lugnut: pretty much
teozkr (Nullable): what if something isn't on any of the lists?
Lugnut: not possible
Lugnut: here's the how it works
Lugnut: dev makes add-on and uploads it > server processes using regex or something, dividing it into 3 categorys, described above > if it's in A, it gets put on the open downloads. if it's on B, it waits for humans to review. if it's on C, it'll probably never see the light of day
Lugnut: list A is a list of add-ons that got approved automatically, but have not been human reviewed
Lugnut: again, the bar to go from A to B is /really/ low
teozkr (Nullable): ahh yeah
Lugnut: ideally... i dunno, 30% make it into A, 65 into B, and 5 into C
teozkr (Nullable): IMO, most add-ons are just stuff like guns
Lugnut: yeah
Lugnut: and most of those would pass straight into A
teozkr (Nullable): which should go into A
teozkr (Nullable): yeah
Lugnut: in fact
teozkr (Nullable): unless they do something very weird
Lugnut: perhaps we could raise and low
Lugnut: yes
Lugnut: exactly
Lugnut: if it has strange checks maybe
Lugnut: just
Lugnut: i don't have examples
Lugnut: but abnormal behavior for guns
Lugnut: like checking for admin
Lugnut: or servercmds
Lugnut: idk
Lugnut: that's probably too low and might catch too many fish
Lugnut: oh, and all these lists would be sorted chronologically
teozkr (Nullable): IMO, guns etc should be under the same scrutiny as everything else
Lugnut: oh yes
Lugnut: but think about this
Lugnut: a server_ mod will probably have isadmin checks
Lugnut: but why does a weapon_ need that?
Lugnut: it's probably not doing anything malicious, but it's /abnormal/
Lugnut: we could probably
teozkr (Nullable): that's true
Lugnut: oh god
Lugnut: if one of us wanted to go all out
Lugnut: nullable
teozkr (Nullable): unless it's a rather overpowered gun :p
Lugnut: we could do statistical brown townysis // like bayesian statistics is what I'm talking about
Lugnut: like spam filtering
Lugnut: if a given item
Lugnut: after /all/ the above regex checks for things like call() and the like
Lugnut: if it passes all of those
Lugnut: but is somehow out of the ordinary
Lugnut: i don't know if we can do that
Lugnut: but that would be like loving AI
teozkr (Nullable): sounds like it'd be cool, but probably also not something for v1.0 :p
Lugnut: oh hell no
Lugnut: v1 will probably have totally manual everything goes into B
Lugnut: shortly thereafter will have other stuff
Lugnut: cause
Lugnut: who wants to do work or anything
Lugnut: trimming 40% of the work just by putting things into A is 2/5ths
teozkr (Nullable): hehe
Lugnut: i'm gonna log most of this down
Lugnut: specifically the idea parts
Lugnut: the delta updates, the list idea
Lugnut: auto parsing
Lugnut: probably skip the bits where i was bitching about other people complaining
teozkr (Nullable): :p
Lugnut: ooh
Lugnut: the mod reviewer interface could do diffs
Lugnut: when a mod is updated, why trawl through the whole codebase?
teozkr (Nullable): yes!
Lugnut: just show the new bits
teozkr (Nullable): though that is something that we'd get for free by integrating with git/mercurial
Lugnut: remind me how this integration would occur?
Lugnut: best I can think of is some kind of git hosting service that doubles as a blockland add-on thing
teozkr (Nullable): not neccessarily
Lugnut: i'm not getting the connection on the add-on developers side
teozkr (Nullable): remember that both git and mercurial use SHA hashes of the commits as identifiers, which means that we could trust an arbitrary host
teozkr (Nullable): so basically we would internally store say "BAM v1 corresponds to SHA audhfoiuhasf"
Lugnut: okay we need to back up just a tad
teozkr (Nullable): when it's approved, run a script that generates the zip
Lugnut: are we talking about BAM developement or BAM add-on hosting?
teozkr (Nullable): well, both
teozkr (Nullable): it makes sense that BAM would use itself to update itself, no?
Lugnut: anything is possible with us savvy users, but how do we use git in conjunction with a random developer updating stuff?
teozkr (Nullable): we could generate bitbucket repositories on a bot account or something
Lugnut: what difference does it make for the v1 thing if we can't go through git repos directly with torquescript? is it not an unneccesary layer of abstraction?
Lugnut: we could initialize them locally
Lugnut: port was saying they'd use [REDACTED??], so that might be hard
teozkr (Nullable): oh
Lugnut: we'd/they'd idk
teozkr (Nullable): yeah that might be a problem then, perhaps
teozkr (Nullable): well I think we could still do stuff that temporarily requires file I/O


[Ipquarx]

Did you seriously say that using eval at all is bullstuff

If so then I'm calling bullstuff on you

On top of that there is no way to guarantee that an addon is safe, none whatsoever.

[Lugnut]

jesus i have stuff to do today why am i getting myself in all these arguments

seriously, three times now i've posted something on the forums and someone has messaged me on steam complaining about it

Code: [Select]

Ipquarx: http://forum.blockland.us/index.php?topic=251611.msg7278072#msg7278072
Lugnut: is that what you just posted in BAM dev
Ipquarx: yes
Lugnut: saw it
Lugnut: i don't remember if i said eval is bullstuff or if it was null
Lugnut: either way it should go under heavy scruitiny
Ipquarx: both
Ipquarx: "Lugnut: c: code red bullstuff - "eval" or "crash" usage. possibly consider banning user depending on severity"
Lugnut: no
Lugnut: my point was that if you use either of those things then they need to be double and triple checked by extremely competent devs
Lugnut: particularly those who have a hankering for finding vulnerabilities
Lugnut: or exploits
Lugnut: what i have there is a sort of dual tiered review system
Ipquarx: and as i said, there is no way whatsoever to guarentee that an addon is safe, the mere idea of automatic approval should go out the window
Lugnut: allowing for us to "hire" other reviewers instead of just having 1
Lugnut: ok
Lugnut: scratch list a
Lugnut: we can still use automated systems to rank add-ons for if they need to be scruitinised more heavily
Lugnut: or s
Lugnut: or something
Lugnut: i dunno
Lugnut: i could point out that rtb did use automated approvals on updates
Lugnut: it came with a big warning, and the mod didn't auto-download them
Lugnut: but it still allowed it
EDIT: stuff, just lost a lot of work and ideas.

let me clarify what I meant by a dual tiered system.
Average reviewer tier: consists of a lot of reviewers, essentially almost anyone that the BAM team knows can code. not everyone, and not public, but still a lot of people.
Administrative tier: A small group of individuals, possibly the BAM dev team, who are known to be trustworthy and are extremely competent or experienced coders.

The review process for an add-on might go something like this:
Add-on is submitted to BAM by add-on dev.
Add-on undergoes automated scanning procedure. Depending on how badass the guy who makes this is, it could use statistics or just plain regex to check for a number of things.
Possible metrics:
Use of TCPObjects. Why do I mention this? Because absolutely frigging no one uses them. A mod that does would be out of the ordinary. This isn't a red flag, but it is a flag nonetheless - even if only a "hey look at this classy add-on" flag.
Use of eval() function. This function is hard to use properly, so an add-on containing it will be scrutinized more closely to avoid accidental (or intentional) exploits.
Use of crash(). Obvious reasons. Possible instant failure of mod. Mod and add-on developer may go up for review by the administrative team, possibly resulting in a ban. Let's call that "Code red."
Improper add-on formatting, such as nested add-ons will probably be instantly failed. Perhaps we could try once to make it work properly, by moving "Script_derp.zip/Script_derp/*" to "Script_derp.zip/*" We won't waste much time on these add-ons though.
If the mod trips a red flag, depending on the severity, it may bypass the lower tier reviewers altogether and require review from administrative level reviewers.
If it doesn't, or it does so over a minor thing, it moves onto the lower tier reviewers, where it will be reviewed and discussed. Probably not thoroughly, and probably only a few minor comments - "hey, I can't figure out wtf is going on at line 25 of derpity.cs. Any ideas?"
Depending on the number of reviewers, and possibly the size/complexity, and if any reviewers flag the mod as needing further review, anywhere from one to many* reviewers will check the mod for proper functionality and security.
If the mod fails because it simply doesn't work, it gets failed and the add-on dev is informed of the issue.
If the mod fails for some other reason, like maybe low quality, it gets failed and the dev is informed.
if the mod fails for a possible security vulnerability, Code red is initiated on the mod and developer.
If the mod succeeds, then it goes up for review by the administrative team. They have the advantage of seeing all the notes of the previous reviewers, so they can hopefully review it quickly (but effectively) so they can get back to other things.
Approval at administrative level causes distribution and release to the waiting masses.

A few notes:
An Administrative level reviewer can review any mod and instantly push it through or decline it, regardless of what stage of review it's at. This sounds like a problem, but you have to understand that the administrative level reviewers are to be /extremely trustworthy/. However, if the mod is up for security review it will remain for security review.
The add-on developer could probably participate in these discussions and comments and concerns during review.
If a user (any user) submits a bug report and marks a mod as malicious, the mod will instantly go back up for review, possibly at a higher priority than before. Perhaps we could even remove the mod from public downloads - it's not like the developers are making money, and I would rather be safe than sorry. However, that leads to a hole in the system where a user could report, say, Pacnet's mods because they hate him. Not good. However, if they were to be wasteful about this, and they cried "wolf", they could easily be banned from marking a mod as malicious.

If a mod is deemed extremely dangerous, given a full or say 75% administrative panel approval, BAM could delete or at the very least deactivate the mod from users blockland installations. "Wow that's a lot of power. Do we want someone to have that?" I dunno. Maybe it'll be opt in, or opt out. The thing is - BAM would be poised in an excellent position to pull down an add-on quickly, allowing a fast reaction time to malicious modifications. It's good if BAM is trustworthy.
Alternate idea: Upon marking it as malicious, a notification is delivered to all users with the malicious mod installed: "An add-on you have downloaded has been discovered to be malicious. Click here for more information." Then it gives you more info. Duh.
It's just an idea.


Sorry, in case you missed that, these are all just ideas. None of them actually represent the actual direction of BAM until Port says so, seeing as he's project lead.

[Scriode]

This will have the information button for server that also have the add-on right? So you can see which players and add-ons the server has (if the server also has BAM)?

[Lugnut]

well that was a lot of words and ideas
thoughts?

[Greek2me]

BAM could delete or at the very least deactivate the mod from users blockland installations. "Wow that's a lot of power. Do we want someone to have that?" I dunno. Maybe it'll be opt in, or opt out. The thing is - BAM would be poised in an excellent position to pull down an add-on quickly, allowing a fast reaction time to malicious modifications. It's good if BAM is trustworthy.

That's the thing. How can I trust this? On that note, do you need any help?

[Conan]

That's the thing. How can I trust this? On that note, do you need any help?

to prevent a caeser the administrative board could be made up of the developers, + 3 non-developer, randomly chosen users that changes every couple of months or so. to prevent trolls nondevelopers can be kicked off the board with a 5-person vote, aka all developers + one non-developer.

[Becquerel]

This looks promising.

[vulnus]

Want me to do a logo?

work:
http://puu.sh/3cFFI.png

If so please give me a good explanation and details on how you want it to be.  Simple, dramatic? what

[Ipquarx]

The review process for an add-on might go something like this:
Add-on is submitted to BAM by add-on dev.
Add-on undergoes automated scanning procedure. Depending on how badass the guy who makes this is, it could use statistics or just plain regex to check for a number of things.
Possible metrics:

• Use of TCPObjects. Why do I mention this? Because absolutely frigging no one uses them. A mod that does would be out of the ordinary. This isn't a red flag, but it is a flag nonetheless - even if only a "hey look at this classy add-on" flag.
• Use of eval() function. This function is hard to use properly, so an add-on containing it will be scrutinized more closely to avoid accidental (or intentional) exploits.
• Use of crash(). Obvious reasons. Possible instant failure of mod. Mod and add-on developer may go up for review by the administrative team, possibly resulting in a ban. Let's call that "Code red."
• Improper add-on formatting, such as nested add-ons will probably be instantly failed. Perhaps we could try once to make it work properly, by moving "Script_derp.zip/Script_derp/*" to "Script_derp.zip/*" We won't waste much time on these add-ons though.

I'd like to add couple to this list. First: Syntax errors.
If a mod you've submitted has a syntax error in it then it should be automatically failed, no matter what.

Second: BL_ID or Name if statements
IE. If your mod has an if statement that executes some code only under the circumstances that someone has/doesn't have a certain BL_ID or name, that should be an instant red flag for a problem user.

1. If a user (any user) submits a bug report and marks a mod as malicious, the mod will instantly go back up for review, possibly at a higher priority than before.

2. If a mod is deemed extremely dangerous, given a full or say 75% administrative panel approval, BAM could delete or at the very least deactivate the mod from users blockland installations.
"Wow that's a lot of power. Do we want someone to have that?" I dunno. Maybe it'll be opt in, or opt out. The thing is - BAM would be poised in an excellent position to pull down an add-on quickly, allowing a fast reaction time to malicious modifications. It's good if BAM is trustworthy.

A couple things about these.

1. This really should not be. If someone marks a mod as malicious, in my opinion, it should give users downloading it a warning that a user has marked it as malicious and that it's awaiting administrator confirmation, and current users of the mod a warning saying the same thing.

The administrators/high level reviewers would then be immediately notified of the claim and would thoroughly review it for possible exploits.

2. I think this is a good idea. In fact, I think it's a GREAT idea. If not deleting it then at the very least adding it to the crap-on list so that it doesn't execute, and giving the user a very obvious warning when they start up a server with it enabled that that mod has been deemed unsafe for use.

Want me to do a logo?
If so please give me a good explanation and details on how you want it to be.  Simple, dramatic? what

Personally, I'd like to it be... Simple, but upbeat. Not minimalistic like the current logo however.

[vulnus]

What kind of font do you want? cursive.. nvm just just me an idea or pick one.

http://www.dafont.com/