Prevent access to internal properties from Ecmascript code even with buffer access about duktape

[svaarala]

Internal properties should also be aligned with ES6 Symbols:

• https://curiosity-driven.org/private-properties-in-javascript

[svaarala]

Prototype branch with a draft that hides internal properties from Ecmascript code but allows user C code to access them:

• https://github.com/svaarala/duktape/compare/hide-internal-properties

This should suffice for sandboxing, but:

• The branch adds an extra flags field to property methods which is of course additional overhead (quite useful for other things too, though).
• It's easy for a user C function to bypass the sandboxing by doing a property lookup using an Ecmascript-supplied key. So it might be better to have an entirely separate C API call to access an internal property (perhaps aligned to the ES6 symbols, e.g. duk_get_prop_symbol() or similar).

[fatcerberus]

I suppose this means Duktape 2.0 will include support for Symbols as well? :)

[svaarala]

Not necessarily, but if changes are made to the internal property model, there should at least be a plan how symbols will be implemented without needing another incompatible change :)

[svaarala]

I'll move this to 3.0.0 because the symbol support is still experimental and making this change makes more sense when that behavior is finalized.

[fatcerberus]

The only Ecmascript binding remaining that can create hidden symbols is Duktape.dec() right? So removing the Duktape binding should be enough of a stopgap until this is implemented.

[svaarala]

Actually no, Duktape.dec() creates a plain buffer as its output right now (maybe changing to Uint8Array to use standard types); one could create a similar buffer by other means. When you convert that buffer to a string, an encoding is applied just like with any other buffer.

[svaarala]

So the remaining risk is C code that pushes unvalidated / un-encoded data using duk_push_string() and creates a hidden Symbol by accident. That's avoided cleanly if C code always encodes/validates strings it pushes to be CESU-8; any other formats will create weirdly behaving strings in any case.