compileFinal is nice but lets improve security even more!

[killzone_kid 1330]

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?

[killzone_kid 1330]

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

[Dwarden 1125]

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

[killzone_kid 1330]

Ah ok makes sense. Would be nice to have it one way or another.

[eddieck 10]

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.

[.kju 3244]

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.

[killzone_kid 1330]

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.

[Dwarden 1125]

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

[galzohar 31]

"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.

[killzone_kid 1330]

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.

[Dwarden 1125]

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 ...

[killzone_kid 1330]

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?

[dmarkwick 261]

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 :)

[Dwarden 1125]

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

[killzone_kid 1330]

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?

[l etranger 5]

If you want to stop the transfer of codes, you should also stop the transfert of strings.

[killzone_kid 1330]

well you might as well explain yourself why do you think strings are bad

[.kju 3244]

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

[killzone_kid 1330]

;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.

[.kju 3244]

'#' (single hash) operator wraps the text with quotation marks.

http://community.bistudio.com/wiki/PreProcessor_Commands#.23

#define MyTag_PublicVariableName #NP01

MyTag_PublicVariableName addPublicVariable ...

[killzone_kid 1330]

;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.

[.kju 3244]

#define MyTag_PublicVariableNameString #NP01

#define MyTag_PublicVariableNameVariable NP01

[killzone_kid 1330]

;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 {};

[l etranger 5]

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.

[.kju 3244]

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