theseion
commented
3 years ago Yes, maybe we should talk about it. As you say, you can basically do, whatever you want:
- modifying the Fuel source will let you monkey patch any object, whether the modifications are ephemeral or part of Fuel itself (e.g. a bad PR)
- modifying the source code of the model that Fuel serializes can produce the same effect.
The code needs to run through serialization. The object lengths are dynamic, so there's no way to know where to skip to in the stream. However, it wouldn't be too hard to do something like #fuelAfterMaterialization and recompile the method to produce an error or warning at the beginning. I wouldn't scrub the source / byte codes, because that will mess with the references that are potentially in there.
That being said, serialized stacks are not runnable, unless you do the extra work to put them into an active process or you execute code manually.
stale[bot]
seandenigris
Continuing the discussion started in #246...
Forgive me if I'm chasing dragons; as I said I'm not an expert in this area. Whether serializing or looking up blocks, couldn't a "creative" person cause arbitrary bytecodes to be executed? For example, couldn't one set the instVars of a block instance to run a dangerous bytecode e.g. in a kernel method? For example:
I wonder if there should be a materialization option whether to materialize blocks at all, or to scrub them so that they are inspectable but not runnable, or some other strategy, or make it pluggable. As @theseion said, the most common Fuel use may be internal/development, but I think even in the dev. context, @svenvc's concern is valid. For example, don't people share Fuel-outs of errors to help debug?