3 ms·
> written with a fair bit of feature flags I see you use Cargo feature for this. One thing to be aware of is Cargo's feature unification (https://doc.rust-lang
by progval 1y ago
> written with a fair bit of feature flags
I see you use Cargo feature for this. One thing to be aware of is Cargo's feature unification (https://doc.rust-lang.org/cargo/reference/features.html#feature-unification https://doc.rust-lang.org/cargo/reference/features.html#feat...), ie. if an application embeds crate A that depends on nova_vm with all features and crate B that depends on nova_vm without any security-sensitive features like shared-array-buffer (eg. because it runs highly untrusted Javascript), then interpreters spawned by crate B will still have all features enabled.
Is there an other way crate B can tell the interpreter not to enable these features for the interpreters it spawns itself?
- ComputerGuru 1y agoNice catch, thanks for pointing that out! This also might be less than ideal if it’s the only option (rather than in addition to a runtime startup flag or a per-entrypoint/execution flag) because one could feasibly want to bundle the engine with the app with features x, y, and z enabled but only allow some scripts to execute with a subset thereof while running different scripts with a different subset.
- aapoalas 1y agoThank you for pointing this out, I'll have to look into this at some point. There is currently no other way to disable features, and at least for the foreseeable future I don't plan on adding runtime flags for these things. I'm hoping to use the feature flags for optimisations (eg. no need to check for holes, getters, prototype chain in Array indexed operations if those are turned off) and I'm a bit leery of making those kinds of optimisations if the feature flags are runtime-controllable. It sounds like a possible safety hole. For now I'll probably have to just warn (potential) users about this.