cfrag

Dear all, my inclination to contribute to DCS has reached an inflection point, and I have decided to withdraw from public contribution for the time being. I thank you all for your kind encouragement and friendship in the past decade, and wish you only the best for the future. -ch

Dear all, my inclination to contribute to DCS has reached an inflection point, and I have decided to withdraw from public contribution for the time being. I thank you all for your kind encouragement and friendship in the past decade, and wish you only the best for the future. -ch

Dear all, my inclination to contribute to DCS has reached an inflection point, and I have decided to withdraw from public contribution for the time being. I thank you all for your kind encouragement and friendship in the past decade, and wish you only the best for the future. -ch

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.

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.

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

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.

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.

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.

DML has completely gone South, and today I do not feel charitable. Any mission using a recent version of DML, Olympus, SSB, or slotblock (i.e. anything Foothold or similar) will no longer work without you changing your DCS install. Expansion, most of the missions I released to UserFiles in the last year, and many interesting missions created by others in the last 24 months are affected. They continue to run, but you must install that godawful "autexec.cfg" <shudder> in the correct location(s). And yeah, that includes your servers. Good luck figuring out which context name corresponds to "scripting" - you may have to rewrite your server scripts. If you can. Fun. If this continues, I foresee that - out of simplicity/convenience - 90% of all DCS installs are set to execute insecure code, completely ruining security - the exact opposite of what the kind people at ED set out to do. Maybe they should have asked someone...

It's really not hard (actually, it's trivial) to patch net.doStringIn() so that a security layer inspects the context and allows or disallows it depending on the mission file that is running, from ission to mission, in the 'mission' environment. The same goes for any other environment. I respectfully contradict your kind message and assert: anyone with access to the interpreter level and a modicum of Lua knowledge can make net.dostringIn() safe depending on the mission that is running. If we have a set of missions that we want to allow unsafe invocations, all we need is a list of their file names. And users could manage that easily, heck even (if you can't be bothered to give that to your customers) have them put in a folder '/unsafe' inside your '/Missions' folder. It's exceedingly easy to manage this, and it looks like no thought has gone into this at all. That's why I'm so disappointed.

Yup, The new release from ED introduces a new, braindead 'security' scheme that prevents scripts in missions from invoking net.dostringIn() unless you create some arcane "autoconfig.cfg" text file in a similarly arcane location. It is simply crap design, and I'm at a loss of words seeing how ED simply did this without bothering to ask the community. The results are far ranging: slotblock (if you play foothold), ssb (another popular slot block), stopGap for multiplayer, twn, radio, ... all require the new 'security' BS. IMHO, the result will be that everyone who wants to play a modern, good mission will have to allow unsafe invocations, and this results in LESS security for DCS than before. What an ill-thought out, idiotic, crude approach to security. Goodness. And ED rammed this atrocity down everyone's throat without ever announcing it or soliciting ideas. Because it is trivial to come up with better solutions, solutions that could help DCS become a modern, player-friendly SECURE app and could ditch the silly 'unsanitize' approach of today. But no, we now have 1980's style "autoconfig.cfg" files. If it wasn't so sad, I would laugh. This is bad. And completely unworthy of ED.

It was. It is used to invoke some code in other environments and pass back data. Regard this snippet: local command = 't = loadfile("' .. path .. '"); if t then t(); return net.lua2json(towns); else return nil end' local json = net.dostring_in("gui", command) if json then towns = {} traw = net.json2lua(json) end Above (plus correct path info of course) reads all towns with their location from any map, and allows scripts to determine where something is, provide better locations, and even determine if a location if worth an attack (it is required because "towns" isn't otherwise accessible in MSE. And it simply worked. Same for radio frequencies, getting the name of the currently running mission (for easy restarts because the trigger version saves a string which buggers versioning). And of course, the venerable SSB (simple slot block) used it to pass slot blocking info. All gone to this 'improvement'

This is atrocious -- I am severely disappointed and aghast. I feel that you (ED and their community managers) could have announced this change more than 24 hours in advance (6 months would have been a better time frame), and perhaps solicited feedback from the community -- because the way that you (ED) chose to implement this sandbox protection scheme is a 1980's design. "autexec.cfg" - are you frigging kidding me? Doesn't anyone at ED understand modern UX and or UI design? Why use such an obsolete and user hostile one-size-fits-all scheme when it would be so much better to build a "sandbox on/off" switch into DCS proper, and then add a simple UI that allow users to add folders to an 'allow unsafe' box that automatically allows unsafe invocations for any mission inside? Users could drag folders/directories and/or missions into the box and - boom! - they allow unsafe invocations. Designing this is (or should be to your talent) near-trivial (I did interface stuff like that in 2 hours -- 2002, on a Mac in XCode!), and a so much better approach for users who grew up with a Mouse. I feel that this new 'design' of yours is unworthy of you, and it feels like such a blatant slap into all of your content creators' face that I am deeply saddened to see how you simply (and callously) implement a far-reaching change like this without ever feeling the need to consult your community and contributors. Are we that worthless to you? That new 'feature' of yours kills any mission that uses net.dostringIn(). You do realise that mission scripters resort to doscript_in because DCS's mission scripting environment requires this to circumvent a bad flaw in MSE's design, do you? This means that any mission today that is sufficiently advanced will stop to work and require that unsafe patch, which will probably result in most DCS installs being unsafe. The exact opposite of security - likely a complete failure of what you set out to do. Why, why, why did you not try to sound out this change with those who spent lots of time creating missions for your product? I would have expected more from you, ED. For the record, can I request that you. or someone from ED, elaborate if you agree that this is merely a coarse stop-gap and that you do have a real, user-accessible and well thought-out future version waiting in the wings? Because this? This is bad design. Will we get a real 'sandbox' security interface for DCS? I don's feel like updating the 50 (?) missions I put on Userfiles, so maybe they run, maybe not. 9 out of the last 10 missions I published there no longer work and now require unsafe invocations. So be it. I cannot be bothered to care if you, dear ED, can't be bothered to engage with your community either. What a mess. I hope that you will fix it soon. Will you, ED?

Update 20250720 - better dynamic traffic Now there's some local traffic on both your departure and destination airfields. Enjoy, -ch