callBound: support --frozen-intrinsics/lockdown?

[ljharb]

When node is invoked with --frozen-intrinsics, many data properties become getters. RegExp.prototype.exec is one example.

Should callBound automatically detect this at all? If so, should it detect --frozen-intrinsics specifically, or not? Either way, would it have to hardcode a list of the exact same data properties that frozen-intrinsics (and SES) convert to getters? (or alternatively, hardcode a list of all the builtins that are supposed to be getters, and auto-handle the rest).

See inspect-js/is-regex#34.

[loynoir]

@ljharb

Can you provide a minimal reproduce using RegExp.prototype.exec and --frozen-intrinsics showing the difference?

Seems like a node.js bug to me now.

[ljharb]

node --frozen-intrinsics -pe 'typeof Object.getOwnPropertyDescriptor(RegExp.prototype, "exec").value === "function"'

It's not a bug, exactly, it's the entire point of the flag - iow, you simply can't ever use that flag without violating the JS spec and breaking nonzero user code.

[loynoir]

@ljharb

inspect-js/is-regex#34 (comment)

While I could work around this, I'm not sure it's a good idea - --frozen-intrinsics simply shouldn't be used for reasons like this, because it breaks assumptions the language otherwise guarantees.

inspect-js/is-regex#34 (comment)

In the meantime, I strongly suggest not using the frozen-intrinsics flag.

Related

nodejs/node#45336 (comment)

🤔

• I want to prevent prototype pollution.

• I don't know any popular/good npm package aim at preventing prototype pollution.

• Manually Object.freeze with HARD_CODE_LONG_LONG_LIST is hard to maintain and might miss something.

• disable-proto doesn't protect constructor.prototype.

• I know frozen-intrinsics is not perfect, but seems to be yet the best solution to prevent prototype pollution, isn't it?

• Or, do you have any library recommended to prevent prototype pollution?

[ljharb]

You simply can't prevent prototype pollution at a broad level without breaking things.