| 00:38 | <Michael Ficarra> | do we want to just talk about all the virtual calls in built-ins? |
| 00:39 | <shu> | i figured you'd want to talk about future designs informed by past experience. i suppose we can also talk about mitigation of existing stuff but i think that's less interesting |
| 00:40 | <Michael Ficarra> | one of my favourites is Array.prototype.toString (https://tc39.es/ecma262/#sec-array.prototype.tostring) calls "join" virtually, meaning replacing Array.prototype.join changes Array.prototype.toString behaviour |
| 00:46 | <Michael Ficarra> | shu: I started a thread for TG3 folks here: https://github.com/tc39/security/issues/7 |
| 00:46 | <Michael Ficarra> | I don't personally think it's of much concern, but I'm open to hearing from others who do |
| 00:49 | <shu> | it's the same shape of risk as adding extra hook points, which as a general category has been responsible for security bugs due optimizing JITs making incorrect assumptions |
| 10:35 | <Ashley Claymore> | Looks like there is an issue with: https://tc39.es/ - getting "github page not found" |
| 10:59 | <yulia> | Ashley Claymore: hmm that happened 2 days ago and then it went up again.. |
| 10:59 | <yulia> | we keep getting invalid domain name for it |
| 10:59 | <yulia> | https://www.whois.com/whois/www.tc39.es |
| 11:00 | <yulia> | i am not sure why it is doing this. might be an issue with our dns provider |
| 11:02 | <yulia> | I wrote the chairs, hopefully we can figure out what is going on |
| 11:02 | <Ashley Claymore> | thank you! |
| 11:05 | <yulia> | this is up though: https://tc39.github.io/ |
| 11:08 | <Ashley Claymore> | ah good point, direct to source. good idea |
| 12:24 | <Jack Works> | https://tc39.es/ecma262/ is 404 |
| 12:24 | <ryzokuken> | Jack Works: on it 👍️ |
| 12:37 | <ryzokuken> | Ashley Claymore: Jack Works it's fixed |
| 12:37 | <Jack Works> | thanks |
| 17:54 | <leobalter> | we're hoping we can actually make this decision as a committee and unblock the proposals that are currently blocked on it Thanks for the info! I'm +1 to unblock with a pragmatic decision, as you seen to be working on it. I'm interested in learning more about the topic. |
| 17:56 | <leobalter> | I'm glad this topic is being brought to the security team. I'll ping my team to have eyes on it as well. |
| 23:13 | <bakkot> | in null[{ toString: () => { console.log('hit') } }] += 1, does it hit the toString or not? SM and ChakraCore think yes; JSC, V8, and engine262 think no |
| 23:14 | <bakkot> | I am pretty sure this changed in https://github.com/tc39/ecma262/pull/2267, but test262 still has tests for the old behavior |
| 23:18 | <bakkot> | test262 test e.g. https://github.com/tc39/test262/blob/df873eed1a717bb59ac8b40f20cf23f19bafb429/test/language/expressions/compound-assignment/S11.13.2_A7.4_T1.js |
| 23:19 | <bakkot> | same question for null[{ toString: () => { console.log('hit') } }]++ |
| 23:19 | <bakkot> | except in that case SM agrees with everyone else in not evaluating the property |
| 23:20 | <bakkot> | or, for that matter, just a plain null[{ toString: () => { console.log('hit') } }], with no assignment at all |
| 23:22 | <bakkot> | the RequireObjectCoercible happens at the GetValue, which happens only when actually trying to get the value, whereas the ToString happens during the Evaluation semantics of a[b]: https://tc39.es/ecma262/multipage/ecmascript-language-expressions.html#sec-property-accessors-runtime-semantics-evaluation |
| 23:32 | <bakkot> | opened an issue on test262 about this: https://github.com/tc39/test262/issues/3407 |
| 23:36 | <bakkot> | and ecma262 I guess: https://github.com/tc39/ecma262/issues/2659 |