Prevent cache tampering by freezing cached value #39
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR freezes the merged class String object before writing it to the cache.
Currently, the
merge
method returns the mutable String object of the cached class string after merging. Here is an example test case that fails:with
This causes some very confusing and hard to debug bugs. Initially, the merger computes the correct value and saves it to the cache. Then the output is modified externally, e.g. because you want to append a class in some special case. For all in-place operations, like
<<
, this changes the cached value. The cache can never recover because the value is not recalculated.The obvious candidates for fixing this are either
.freeze
on the cache value, like in this PR, or.dup
on the return value of themerge
method. I picked.freeze
because it comes with almost no additional computational penalty. I imagine that in the vast majority of cases, the consumer won't need to modify the merged classes. So spawning a new String object on every request seems wasteful. Also Ruby is moving forward to freeze all strings by default in 3.5. The downside is, that.freeze
is a breaking change. But then again, it probably mostly breaks code that had unnoticed bugs, so it seems justified.Results of my test suite indicate, that
.freeze
doesn't affect the computation speed..dub
performs 10% worse when the cache isn't overflowing and equally to.freeze
once the cache size is exceeded. Here are some results:This is the suite: