| 00:45 | <Kris Kowal> | Apropos of this, Agoric uses a variant of XS that can start from a heap snapshot and it would be neat for us to be able to take advantage of that with a test262 runner. |
| 00:50 | <bakkot> | this bug is genuinely cursed: https://github.com/bjrjk/CVE-2022-4262/blob/main/FA/FA.md it relies on
good example of a real-life security issue arising as a direct consequence of making the language so complicated. |
| 09:51 | <yulia> | wow that is a doozy |
| 13:32 | <littledan> | ES6 broke a lot of assumptions that engines could previously make in their parser/bytecode generator, eg around scoping and what can occur in an expression position. Fortunately we haven’t touched that area very much since ES6. Maybe the most significant thing we have done is private fields/methods (which involve scoping), the biggest Stage 3 one is decorators (which add evaluation into new places), and the biggest future thing is do expressions (which I expect to be nontrivial to implement for this reason in some engines, even if they omit break/continue/return, but those certainly make this surface much bigger) |
| 13:32 | <littledan> | There were lots of other bugs in the process that just got caught sooner somehow or other |
| 15:39 | <Michael Ficarra> | class fields and class static blocks probably fall into the category of new expression positions that could cause these kinds of implementation errors, too |
| 15:47 | <littledan> | agreed. something notable is that we did a lot of these changes in ES6, and then subsequent ones are fewer and farther between, somehow. |
| 17:07 | <Jack Works> |
do expression is coming~ |
| 22:18 | <shu> | private fields have the super weird heritage position scope |
| 22:18 | <shu> | that's separate than the lexical scope |
| 22:18 | <shu> | i wouldn't be surprised if there's a CVE in there somewhere |