Jump to content
Sign in to follow this  
killzone_kid

compileFinal is nice but lets improve security even more!

Recommended Posts

Dear devs, why don't you add another parameter to description.ext, something like this

allowCodeOverNetwork = 1;

you can send code with publicVariable or BIS_fnc_MP or other functions

allowCodeOverNetwork = 0;

trying to transfer code over network will throw error and log in offending client

This way mission makers can chose exactly how they want their mission to run.

Please?

Share this post


Link to post
Share on other sites

why was it moved here? description.ext doesnt mean server administration. there was no harm in leaving it in arma 3 alpha subforum

Share this post


Link to post
Share on other sites

mission maker shall not determine how this behave

because there are also server side addons / scripts and complex modifications / total conversions

which may use the variables etc. over network

so enforcing this in description.ext inside mission file would break anything outside

such setting should be in hands of server admins as server.cfg setting (either global setting or per mission setting)

e.g. as part of

http://community.bistudio.com/wiki/server.cfg#ArmA_II:_Operation_Arrowhead

or

http://community.bistudio.com/wiki/server.cfg#ArmA_II:_Operation_Arrowhead_-_multiple_mission_parameters_configuration

config

Share this post


Link to post
Share on other sites
Dear devs, why don't you add another parameter to description.ext, something like this

allowCodeOverNetwork = 1;

you can send code with publicVariable or BIS_fnc_MP or other functions

allowCodeOverNetwork = 0;

trying to transfer code over network will throw error and log in offending client

This way mission makers can chose exactly how they want their mission to run.

I'm all for a feature that would prevent certain commands from being called from the client.

The thing is, PV has legitimate uses (actually, PVserver is the only thing that should be possible from the client). It's not up to BIS to prevent dumb mission developers from PVing code...

mission maker shall not determine how this behave

because there are also server side addons / scripts and complex modifications / total conversions

which may use the variables etc. over network

so enforcing this in description.ext inside mission file would break anything outside

such setting should be in hands of server admins as server.cfg setting (either global setting or per mission setting)

Have you considered the idea of providing this flag for both missions and mods? The server could enable it only if the mission and all running mods have it enabled.

I prefer this as it doesn't require any explicit configuration from server admins, some (but not all!) of which are clueless. Even now a few of the most popular (according to http://arma3.swec.se) A3 servers do not have verifySignatures enabled.

Share this post


Link to post
Share on other sites

What cases do you see the require code to be sent over network?

Normally sending just the data and have local execution does the job.

In terms of servers: of course we need more reasonable defaults like BE active, sig check active.

All that involves security should be set to max by default and only experienced admins are to reduce the level by decision/action.

Share this post


Link to post
Share on other sites

According to wiki for publicVariable

Since version ArmA v1.09: Any value can be transferred, including

Array

Code

I would also like to know in which cases you absolutely must transfer code and trying to solve the problem in other ways would result in inferior solution.

Share this post


Link to post
Share on other sites

it's not about must transfer code, it's about you may ... I used it often either for dynamic cod , sometimes effects and admin camera system ... this way allowed me to keep mission file at minimal size, saving 10s to 100s kB per mission file

Share this post


Link to post
Share on other sites

"Must transfer code" only happens if not everyone are running the same mods. If everyone are running the same mods you should always be able to use a better solution.

As long as a server can enforce everyone to start with the same game state at the start of the missions (aka, no out-of-mission functions re-defined to do malicious or just non-functional stuff and no unauthorized mods to do the same), then the playing environment should be secure. The compileFinal stops the overwriting of game functions, verifySingatures stops the unauthorized mods, and as far as I'm aware, Battleye stops (or tries to stop) the more complex hacky stuff.

Share this post


Link to post
Share on other sites
it's not about must transfer code, it's about you may ... I used it often either for dynamic cod , sometimes effects and admin camera system ... this way allowed me to keep mission file at minimal size, saving 10s to 100s kB per mission file

You'd be surprised how much KBs you can save by simply removing tabs and end of lines with notepad++ from mission and script files.

Share this post


Link to post
Share on other sites
You'd be surprised how much KBs you can save by simply removing tabs and end of lines with notepad++ from mission and script files.

i parser for that and use it quite often, so this note is irrelevant, for me it has reason to got the mission file as smaller as possible, same goes for the dynamic data flying over network or else ...

Share this post


Link to post
Share on other sites
i parser for that and use it quite often, so this note is irrelevant, for me it has reason to got the mission file as smaller as possible, same goes for the dynamic data flying over network or else ...

Can I ask you a question? Does the name of your PV matter to the size of packets sent? if I send 100 PVs "ThisismyPV" and 100s "PV" will the second method take less bandwidth?

Share this post


Link to post
Share on other sites

I suppose it depends on whether you wish for your addon to have an effect outside of other people's ownership of that addon. I had complaints that F&S was generating log entries on people's RPT files when they did not have the addon, so I had to wrap it in

if (isClass (configFile >> "cfgPatches" >> "JTD_FireAndSmoke")) then {....}

etc.

But, I think in future people are just going to have to use the addon or simply suffer the log entries :)

Share this post


Link to post
Share on other sites

definitely if you use too long variable names for something what's used very often then it might have some negative effect on amount of data floating over network

so short is fine, but too short is risky and might create e.g. collision with other scripts/addons/mods ...

so I use often e.g. prefix_name_suffix ... like dw_AIgrps_rnd or dwa_cleanup_rnd

Share this post


Link to post
Share on other sites
definitely if you use too long variable names for something what's used very often then it might have some negative effect on amount of data floating over network

so short is fine, but too short is risky and might create e.g. collision with other scripts/addons/mods ...

so I use often e.g. prefix_name_suffix ... like dw_AIgrps_rnd or dwa_cleanup_rnd

thanks. do you use any compression on the data sent since it is mostly text and probably would nicely compress and decompress on the fly?

Share this post


Link to post
Share on other sites

the length of var names is basically irrelevant in 99.x% for network traffic.

so descriptive naming is far better for its better code quality

if you really have something sent extremely often, aka many times per second, use defines instead:

#define MyTag_PublicVariableName NP01

Share this post


Link to post
Share on other sites
;2384792']the length of var names is basically irrelevant in 99.x% for network traffic.

so descriptive naming is far better for its better code quality

if you really have something sent extremely often' date=' aka many times per second, use defines instead:

#define MyTag_PublicVariableName NP01[/quote']

How would this sit with PV event handler? I dont think preprocessor will change "MyTag_PublicVariableName" addPublicVariable.... to "NP01" addPublicVariable.... automatically.

Share this post


Link to post
Share on other sites
;2384814']http://community.bistudio.com/wiki/PreProcessor_Commands#.23

#define MyTag_PublicVariableName #NP01

MyTag_PublicVariableName addPublicVariable ...

Yeah I know that, but you will have

MyTag_PublicVariableName = value

publicVariable "MyTag_PublicVariableName"

"MyTag_PublicVariableName" addPVhandler

with and without "" at the same time.

Share this post


Link to post
Share on other sites

#define MyTag_PublicVariableNameString #NP01

#define MyTag_PublicVariableNameVariable NP01

Share this post


Link to post
Share on other sites
;2384828']#define MyTag_PublicVariableNameString #NP01

#define MyTag_PublicVariableNameVariable NP01

Nah. Namespace to the rescue!

#define MyTag_PublicVariableName #NP01

missionNamespace setVariable [MyTag_PublicVariableName, _value];
publicVariable MyTag_PublicVariableName;
MyTag_PublicVariableName addPublicVariableEventHandler {};

Share this post


Link to post
Share on other sites
well you might as well explain yourself why do you think strings are bad

_code={player setdamage 1;};

_string ="{player setdamage 1;};";

call _code;

call compile _string;

Both have the same result.

That's why removing code transfert doesn't change much. The only thing BIS can do if they don't want to change Arma 3 architecture (I'm my opinion, they should change it, Alpha is still the time to do) is to remove the integrated local client code receive & execution functions. Which is what they are doing with the remove of the SVI PCI commands. Then people have to make their own for they addons / missions if they need to execute code on remote machine (with all the safety issue it can be). But It will not be inside as basis.

Share this post


Link to post
Share on other sites

remote execution has to go no matter what - in all forms

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×