Email or username:

Password:

Forgot your password?
Top-level
bluca

@pid_eins @phako not really, JS was chosen because you need to be able to express complex configuration rules, and it's better to use a known tool than inventing a new one. It's not about IPC, the transport doesn't matter, you need a configuration-like DSL because it's unfeasible to ask every admin/user to write and deploy a new program every time some rule needs to be adjusted.

8 comments
Lennart Poettering replied to bluca

@bluca @phako I don't see why dropping in a JS-based varlink mini-service would be any harder than dropping in a PK JS fragment. you get a function call with a JS(ON) object, you answer it with a JS(ON) object. done.

But by doing this via a Varlink IPC call you gain security (i.e. that stuff runs out of process), and make it generic (i.e. people can chose other languages than JS)

bluca replied to Lennart

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

Lennart Poettering replied to bluca

@bluca @phako i don't follow why running JS embedded would make anything "easier" than running it as a process of its own?

bluca replied to Lennart

@pid_eins @phako it's not about running, it's about writing, deploying, maintaining

Simo ✔️ replied to bluca

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

Simo ✔️ replied to Simo

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

bluca replied to Simo

@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

Simo ✔️ replied to bluca

@bluca @pid_eins @phako there are countless programs that have a simple .ini file for configuration where all you do is set variables.
Hyperbole does not help.
Pretty sure 99% of what pk is used for can ne done with a plain config filr, whether tha is implemented as .ini or a more structured .json or similar.
The cases where you need a program to compute behavior at runtime is vanishingly small.

Go Up