Re: [w3c/IndexedDB] Transactions should be marked as inactive during key serialization (Issue #476)

evanstade left a comment (w3c/IndexedDB#476)

Thanks for reporting.

The original Chromium change said "the getters can invoke other write operations, resulting in a stack overflow and renderer crash" but is otherwise light on details of how this could be weaponized. I actually don't see a renderer crash when I remove Chromium's mitigation and change `structured-clone-transaction-state.any.js` to call `objectStore.put` recursively (instead of non-recursive `objectStore.get` inside the property getter). So there doesn't seem to be an actual renderer crash or security vulnerability here AFAICT. Was there something different in 2019? Instead of a crash, v8 throws the same `RangeError: Maximum call stack size exceeded` error mentioned above.

I think generally I would have been in favor of NOT explicitly mitigating this in the spec or in the implementation, for the sake of simplicity and given that the `RangeError` seems entirely reasonable. At the end of the day, we're just throwing a different type of error, and one that is arguably more confusing --- the `RangeError` tells you you recursed too much, whereas the `TransactionInactiveError` is surprising/confusing because the transaction is inactive only very transiently. Granted it's probably rare anyone trips up on this accidentally.

That said, I agree that consistency is sensible here.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/476#issuecomment-3422962634
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/IndexedDB/issues/476/3422962634@github.com>