Enforcing amends of a builtin schema / untrusted pkl code

[jwhitaker-gridcog]

Hey guys,

I have a possible "x / y" problem - what I think I want now is a way to evaluate an arbitrary pkl input, in a way that confirms it matches my pre-determined schema. E.g. if I have a schema

class Point { x: Int, y: Int }
p: Point

How can I use either/both pkl eval or the pkl language bindings to read an arbitrary valid config like

amends "schema.pkl"
p = new { x = 1, y = 2 }

and accept it, or read an arbitrary invalid config like

amends "schema.pkl"
// amends, but differs in schema
p = new { x = 1, y = 2 }
foo = "bar"

or

// valid pkl, but doesn't attempt to amend
foo = "bar"

and reject it?

As far as I can tell, the existing language bindings+codegen do not actually enforce that the read config matches the codegen'd types. E.g. if I'm reading the Typescript codegen correctly, it is only going to be sound if the codegen is run against the final runtime pkl; if your schema pkl and runtime pkl differ then nothing is going to catch this and you'll footgun yourself.

---

The possible "x / y" nature of the problem is I'm considering allowing untrusted user input to be in pkl format. Is this considered a safe / bad idea in general?

---

Thanks! Also apologies if I'm misreading something or missing something obvious, this seems like quite a basic thing so i've probably overlooked something.

[HT154]

Your "accept it, or read an arbitrary invalid config" case is fortunately impossible! Pkl will not allow introduction of new properties when amending a module, only when extending (which requires the extended module to be open/abstract).

You're right that there's a potential issue with the completely unrelated module and I think this is probably worth an issue on the pkl-go and pkl-swift repos.

That said, this may be a touch problem to solve. I've only tested pkl-go and doing this indeed returns no error: it prints a warning that the unknown field(s) were found and happily returns a struct with zero values for each field. pkl-go is behaving similar to how unmarshalling JSON into a struct would behave. That's not terribly surprising behavior in this context but might be surprising in other languages.

[jwhitaker-gridcog]

Yeah the typescript one is a bit scarier: go at least gives you a struct with the right fields, even if they end up zeroed. With JS you could end up with something completely different to its promised type, e.g.

const res:{p:Point} = load(...) // == 'yo dawg'

Aside from the codegen'd bindings, is there a good way to go about checking this in the CLI? Or with the pkl-core / pkl-config-java/kotlin libs?