Changes to the behaviour of net.dostring_in()

[Special K]

vor 3 Stunden schrieb 392198523:

Yep, that's a 2 lines change which totally ruins our newly introduced enhanced security.

Not sure how a change that adds security ruins whatever you had done as you don't even have access to where these changes were made.

vor 5 Stunden schrieb MarcosR:

Can someone confirm is working? I can't make it work in rotorheads..

Can execute, but cant receive any data.

 

AFAIK you guys use my bot? At least you did in the past. If you do, all you need is make sure you're using the latest version.

vor 2 Stunden schrieb Buta:

How can I know what those "server", "mission", "scripting", "gui", "export", "config", "zone" mean and what they can do? I hope the answer won't be "guessing", "trying" and "testing". Is there a doc to explain this api?

If you don't know what they do, you probably don't need them. 

For the guys that are building mods and script stuff it should be very obvious what is what.

vor 47 Minuten schrieb Mr.Jazzy:

If mod makers are licking fingers after this feature, what kind of mods are we talking about?

Any mod that needs to pass information between the different secure zones.

[Special K]

vor 18 Minuten schrieb cfrag:

No discussion here. DCS needs good, scalable and easy to maintain security. In the past, I have recommended a couple of approaches in these forums how, for example, DCS could easily sandbox (better: sidestep) the lfs 'sanitize' issue by allowing a controlled, sandboxed 'writeString()' method that saves a string to a mission without having to 'de-sanitize' DCS (and compromise security). It was never followed up on. Pity. Instead we got the 'save mission' system that simply doesn't work, solves no problem at all, lfs still needs to be de-sanitized using a really, really bad 'unlock this for everyone' approach, just like this approach for dostring_in(). And to truly underscore how bad things are, the two approaches to resolving related issues (security) aren't harmonized. To me this is indicative of deeper troubling issues at ED than merely a bad IT security design team.

The problem is that this new 'enhanced security' is, as implemented now, utter garbage; an inept, heavy-handed approach that will lead to LESS security. Why? Because soon (if they haven't already) videos and article will appear that tell you how to 'fix DCS' when all these "attempt to call field dostring_in" errors pop up in-mission. Invariably they will tell you to 'simply place this autoexec.cfg here, and you are done'. Because of the hare-brained one-size-fits-all approach, now the entirety of DCS is open, for every mission (not to mention providing a new attack vector through a malicious autoexec.cfg that is provided by the attacker in the video). Anyone with merely passing working experience in security can tell you: this approach is bad, much worse than not doing anything.

So my opinion: this 'security' design is utterly inept, and it results in REDUCING security because everyone will bypass this 'security' for their comfort. Its like putting a fantastically complicated lock on your front door. Because it inconveniences everyone, they just keep it unlocked, opening the door for anyone. Is that improved security?

A better design would allow per-mission sandboxing. There a billions of possible approaches: put the mission in a folder /insecure, and if it is in there, use the settings screen in DCS to regulate what is allowed (and yeah, lfs and io should be in there too). Better yet: have a GUI for that allows players to drag missions/directories into. Any mission in there is allowed risky stuff (configured by the GUI). Simple, and it does not take a lot of talent to implement. I'm not saying that above is good security design. Far from it. I'm merely saying that it's better by orders of magnitude than the current, inept design. What deeply troubles me is the fact that something this badly designed has made it past the design stage. What angers me is that it made made it into production. ED - you have a serious quality issue. Cheap, badly thought out code like this should never make it to the customer.

This is really, really bad, ED. Please fix it. And please, if you don't have the talent, I'm sure there is ample talent in the community to help you out. Just ask.

I understand your frustration but the reality is different. It's not to add any more security for mission builders or scripters or to make the world of server admins more difficult.

It's to add security to the casual DCS user that does not need any of that but that loads a mission from anywhere and runs it. These people need to be protected and that's the obligation of ED which they took responsibility of here.

[Veltro3]

Personally I have only worked on server-side mods and I have little experience in mission scripting. I think the changes ED have introduced can be very interesting for server-side mods, intended for more advanced users. However, now knowing that missions also leverage dostring_in and have now been blocked, I do agree with @cfrag's point that soon someone will just make a post somewhere saying to simply copy these lines in autoexec.cfg and enable absolutely everything. I think the idea behind the change is good and needed but the approach may require some tuning. 
 

[Special K]

vor 1 Minute schrieb Veltro3:

Personally I have only worked on server-side mods and I have little experience in mission scripting. I think the changes ED have introduced can be very interesting for server-side mods, intended for more advanced users. However, now knowing that missions also leverage dostring_in and have now been blocked, I do agree with @cfrag's point that soon someone will just make a post somewhere saying to simply copy these lines in autoexec.cfg and enable absolutely everything. I think the idea behind the change is good and needed but the approach may require some tuning. 
 

But that's the same argument you could have for MissionScripting.lua. People do not just blatantly open up all gates, just because some mod might need it. It's like always, we need to get used to it. And we will.

[cfrag]

5 minutes ago, Veltro3 said:

soon someone will just make a post somewhere saying to simply copy these lines in autoexec.cfg and enable absolutely everything.

It seems a likely outcome. I put up some 50 missions on ED's user files, and they (guesstimate) clock in at some 30'000 downloads. Half of them will no longer work today unless the entire DCS install is unlocked.  

Edited Thursday at 07:07 AM by cfrag

[Veltro3]

3 minuti fa, cfrag ha scritto:

It seems a likely outcome. I put up some 50 missions on ED's user files, and they (guesstimate) clock in at some 30'000 downloads. Half of them will no longer work today unless the entire DCS install is unlocked.  

Ignoring for a second the probability of people really unlocking everything, why are you saying that it is NEEDED? You can just enable mission to gui dostring_in, if that is what is needed.

[cfrag]

9 minutes ago, Veltro3 said:

You can just enable mission to gui dostring_in, if that is what is needed.

That is true. And it requires that anyone who does this knows what they are doing. 99% of them do not, and do not care. They will copy/past someone's solution, and that one is virtually guaranteed to unlock all environments, if it's not a maliciously crafted script itself.

Any solution that requires a user to know some arcanae is a bad solution. Any solution that relies on detailed user know-how in coding is sensationally bad. This solution requires both: that a user feels comfortable editing a code file, and know what the terms inside like 'gui' and 'mission' mean. You just lost 99.99% of all ED customers. Most have the ability, yes. But they can't be bothered. They will copy/paste.

Edited Thursday at 07:20 AM by cfrag

[Veltro3]

Could be worth adding a list of checkboxes that can be set in the DCS Launcher that allows users to enable/disable permissions? Could be done pretty easily IMHO

Edited Thursday at 07:26 AM by Veltro3

[Buta]

1小时前，Special K说：

If you don't know what they do, you probably don't need them. 

For the guys that are building mods and script stuff it should be very obvious what is what.

If a beginner wants to get started with DCS mission scripting, how should they learn it?

I've used the APIs mentioned at https://www.digitalcombatsimulator.com/en/support/faq/scripting_engine/ and created several missions like dynamic helicopter logistics and custom dynamic campaigns for MP servers. I don't have any other "teachers" currently.

Now I want to learn about "net", especially the "net.dostring_in()", but I find it very difficult to find relevant documents. I’ve checked Hoggit’s documentation (which has been incredibly helpful!), but noticed the "net" section hasn’t been updated in some time.

Guessing or testing trial-and-error has slowed my progress, and I’d really value concrete guidance. Thanks for your help.

[AvgeekJoe]

Simple questions as an end user:

1) Is this going to mess up MIST or MOOSE?

2) Is this going to mess up the EW script?

 

[392198523]

11分钟前，AvgeekJoe说：

Simple questions as an end user:

1) Is this going to mess up MIST or MOOSE?

2) Is this going to mess up the EW script?

1) As far as I am concerned, No. (But from my opinion, MIST is a legacy script and is lack of maintenance for almost a year. You better avoid using it.)

2) No.

[cfrag]

2 hours ago, Special K said:

If you don't know what they do, you probably don't need them. 

That is an incredibly dangerous assumption. Run the below mission on a secured DCS install. It will throw an error. Any of the missions I have put up on User Files (and that enjoy moderate popularity) in the past 12 months will immediately stop at mission start, throwing that error. Perhaps try this one: 

Error on start.

"Joe User" who downloads such a mission will not know what to do, and they now need to know what to do to run a simple mission. This is bad.

crash my clients.miz

Edited Thursday at 09:19 AM by cfrag

[Special K]

vor 2 Stunden schrieb cfrag:

It seems a likely outcome. I put up some 50 missions on ED's user files, and they (guesstimate) clock in at some 30'000 downloads. Half of them will no longer work today unless the entire DCS install is unlocked.  

So you mean you're using net.dostring_in in all possible contexts with all possible scopes? I doubt that.

vor einer Stunde schrieb Buta:

If a beginner wants to get started with DCS mission scripting, how should they learn it?

I've used the APIs mentioned at https://www.digitalcombatsimulator.com/en/support/faq/scripting_engine/ and created several missions like dynamic helicopter logistics and custom dynamic campaigns for MP servers. I don't have any other "teachers" currently.

Now I want to learn about "net", especially the "net.dostring_in()", but I find it very difficult to find relevant documents. I’ve checked Hoggit’s documentation (which has been incredibly helpful!), but noticed the "net" section hasn’t been updated in some time.

Guessing or testing trial-and-error has slowed my progress, and I’d really value concrete guidance. Thanks for your help.

Unfortunately, the documentation is a thing. There's not "the" source and what we get from ED is very limited.

I am on vacation rn, so I can not write up an essay about it. If you just started scripting it is quite unlikely that you need this specific API. You can use it for instance to call a function from your Hooks environment inside of the running mission. Or you can now read values from your mission from the Hooks. That can be useful for persistency frameworks, statistics etc.

[Special K]

vor 55 Minuten schrieb cfrag:

That is an incredibly dangerous assumption. Run the below mission on a secured DCS install. It will throw an error. Any of the missions I have put up on User Files (and that enjoy moderate popularity) in the past 12 months will immediately stop at mission start, throwing that error. Perhaps try this one: 

Error on start.

"Joe User" who downloads such a mission will not know what to do, and they now need to know what to do to run a simple mission. This is bad.

crash my clients.miz 11.31 kB · 0 Downloads

Yes, it puts the burden on those who developed the scripts to tell people how to run them / what to do to run them. I agree that this is not great but it is how it is now.

My message was meant to the guy who seemed to be a starter in regards of DCS scripting.

[cfrag]

1 minute ago, Special K said:

So you mean you're using net.dostring_in in all possible contexts with all possible scopes? I doubt that.

My apologies for being obscure. I use doString_in all missions (it's a framework I use, DML, and its 'common' bedrock that provides all services uses dostring_in(), it uses at least one context. The number of contexts used is immaterial. A user who does not know the origins of the error, and who did not open their DCS install, will suddenly receive an error. Because by default, invoking doString_in, no matter which context, produces a nil error. 

Someone who until yesterday could happily play all these missions and who did not set up an autoconfig file will today have the mission stop with an error. 

[Special K]

Gerade eben schrieb cfrag:

My apologies for being obscure. I use doString_in all missions (it's a framework I use, DML, and its 'common' bedrock that provides all services uses dostring_in(), it uses at least one context. The number of contexts used is immaterial. A user who does not know the origins of the error, and who did not open their DCS install, will suddenly receive an error. Because by default, invoking doString_in, no matter which context, produces a nil error. 

Someone who until yesterday could happily play all these missions and who did not set up an autoconfig file will today have the mission stop with an error. 

Understood. Yeah, I fear you need to add that autoexec.cfg to the mission downloads now. At least that would be the most convenient way for people.

Gerade eben schrieb Special K:

Understood. Yeah, I fear you need to add that autoexec.cfg to the mission downloads now. At least that would be the most convenient way for people.

I did my best to tell the support guys what to do if they see these errors also, they have a sample autoexec.cfg in place if a user reports it.

[Special K]

vor einer Stunde schrieb AvgeekJoe:

Simple questions as an end user:

1) Is this going to mess up MIST or MOOSE?

2) Is this going to mess up the EW script?

 

No issues with MIST and Moose AFAIK. I don't know the EW script but as long as it's not passing information between Hooks and the mission, then it will not be affected.

LotAtc is, DSMC, DATIS and from the looks of it DML. I'm still in contact with the Tacview guys about it, can't tell there yet.

[Buta]

35分钟前，Special K说：

So you mean you're using net.dostring_in in all possible contexts with all possible scopes? I doubt that.

Thank you very much for using your precious vacation time to answer questions!
Last week, I tried and found that net.dostring_in('mission',... ) can be used to call functions that are not available in Mission scripting in the mission environment, such as trigger functions in ME (those 'a_*' series of functions).
For example, if I want to "dynamically" show pictures to several player units, I can use the following method:

-- assume I have defined 'imgPath', 'unitID' 
local cmdString = string.format('a_out_picture_u(%d, "%s", %d, %s, %d, "%d", "%d", %d, "%d")',unitID, imgPath,1,'false',0,1,1,30,0)
net.dostring_in('mission',cmdString)

If used in this way, there will indeed be a large number of net.dostring_in() in the script. So sad that this has been changed just after I found them out XD.

[Kang]

3 hours ago, Special K said:

Understood. Yeah, I fear you need to add that autoexec.cfg to the mission downloads now. At least that would be the most convenient way for people.

Yes, but hasn't that been @cfrag's entire point, quite exactly?

[eekz]

By the way, why wouldnt you just add a checkbox in DCS menu that would do the same thing as autoexec?
The problem is that it seems nobody accounting the fact that majority of users won't bother going to cfg files and editing them.

Want an automatic spawn? go donwload and install the script, want a mission to work? - edit .cfg.. etc.
Users are not coders, and have better things to do thant editing files in order to try something new.

Give some love to UX please, that's what DCS needs for years. Despite being probably on of the best products outhere in terms of APIs, scripting, it severely lacks in UX/UI

Edited Thursday at 01:19 PM by eekz

[Special K]

vor 3 Stunden schrieb Buta:

Thank you very much for using your precious vacation time to answer questions!
Last week, I tried and found that net.dostring_in('mission',... ) can be used to call functions that are not available in Mission scripting in the mission environment, such as trigger functions in ME (those 'a_*' series of functions).
For example, if I want to "dynamically" show pictures to several player units, I can use the following method:

-- assume I have defined 'imgPath', 'unitID' 
local cmdString = string.format('a_out_picture_u(%d, "%s", %d, %s, %d, "%d", "%d", %d, "%d")',unitID, imgPath,1,'false',0,1,1,30,0)
net.dostring_in('mission',cmdString)

If used in this way, there will indeed be a large number of net.dostring_in() in the script. So sad that this has been changed just after I found them out XD.

I am using exactly that in my bot, which is running on some 550 servers these days. And there is no issue at all in doing it, people just need to add the 2 lines.

If your server is either using my bot or running on one of the big hosters like Fox3 or MasterArm, you are good already also. So it will affect self-hosted servers, yes, but again, just add 2 small lines and you are happy.autoexec.cfg

 

vor 35 Minuten schrieb eekz:

By the way, why wouldnt you just add a checkbox in DCS menu that would do the same thing as autoexec?
The problem is that it seems nobody accounting the fact that majority of users won't bother going to cfg files and editing them.

Want an automatic spawn? go donwload and install the script, want a mission to work? - edit .cfg.. etc.
Users are not coders, and have better things to do thant editing files in order to try something new.

Give some love to UX please, that's what DCS needs for years. Despite being probably on of the best products outhere in terms of APIs, scripting, it severely lacks in UX/UI

There would be the need to do it at 2 places, because you need to either do it in the GUI for clients or in the WebGUI for servers. And yes, that is an option. We do not have this option for anything in MissionScripting.lua also since ever (which does not make it better, but just as a reference).

The majority of people will just not need it at all.

[The Stick]

6 hours ago, cfrag said:

That is an incredibly dangerous assumption. Run the below mission on a secured DCS install. It will throw an error. Any of the missions I have put up on User Files (and that enjoy moderate popularity) in the past 12 months will immediately stop at mission start, throwing that error. Perhaps try this one: 

Error on start.

"Joe User" who downloads such a mission will not know what to do, and they now need to know what to do to run a simple mission. This is bad.

crash my clients.miz 11.31 kB · 0 downloads

Well, your Sinai Tourist mission worked like a charm - just flew from Ben Gurion to Cairo. Happy to report there was neither a hitch nor a hiccup

 

[Amarok_73]

7 hours ago, AvgeekJoe said:

Is this going to mess up MIST or MOOSE?

Just search the MIST or MOOSE for "net.dostring_in" and You'll know from where to expect unexpected.

[okopanja]

why would a normal user need to easily enable this?

It's equivalent of download program from internet and run it.

[cfrag]

1 hour ago, okopanja said:

why would a normal user need to easily enable this?

To run any mission that uses a script with dostring_in(). If they do not enable it, the formerly running mission stops with an error. Try this: 

Won't run on a fresh, secure DCS install. It did so until yesterday.

Edited Thursday at 05:30 PM by cfrag