Gregory's Server@pid_eins @phako because writing a new config file and writing a new running program are not the same thing, and while for us developers there's not much difference, for non-developers the difference is huge. JS was already a though sell because, while the dialect used is minimal and restricted, it's still potentially a full-blown language. Dealing with writing and deploying and maintaining fully independent executables would be way too much. You need dependency tracking, pipelines, etc etc.
|
6 comments
@bluca @pid_eins @phako writing js is as hard as any other program, and it is turing complete which makes "configuration" uncheckable (unless you solved the halting problem) and this is definitely not good security. A decent basic configuration set + extension via IPC for those extremely rare cases where you would need it (and that you can block) would be much better from a security pov. @bluca @pid_eins @phako Most people can't think adversarially when writing code, which means using js to configure access to a high privileges is very risky. And can't be easily checked for correctness. If you do anything more complex than just assigning variables you risk opening huge holes by not paying attention at how things are evaluated. @simo5 @pid_eins @phako there can be no "decent basic configuration set", that's the point - otherwise it would be there. It's been working like this for a decade, and it's been just fine as it's simple enough do to the variety of basic things that everybody need. The problems aren't there, they are elsewhere, and requiring users and admins to become software developers and supply chain managers is not a realistic or good or desirable solution @bluca @pid_eins @phako there are countless programs that have a simple .ini file for configuration where all you do is set variables. |
@bluca @phako i don't follow why running JS embedded would make anything "easier" than running it as a process of its own?