| 19:15 | <bradleymeck> | how do people feel about trying to work on mitigating prototype pollution vulnerabilities in user land libraries that the JS ecosystem is seeing a lot of |
| 19:15 | <bradleymeck> | we can't patch overwrite mistake, but maybe we could make own properties more developer friendly to deal with? |
| 19:18 | <bradleymeck> | basically the problem is libraries are doing `object[key]` on arbitrary input and by default some builtin prototypes allow for crawling to codegen etc. |
| 19:21 | <bradleymeck> | on a glance no builtin types allow for codegen based purely off own property traversal unless you have access to the root intrinsic. E.G. to get to Function.prototype.constructor via own property traversal you have to get to Function or Function.prototype, which most userland libraries are not generally called with |
| 19:23 | <devsnek> | bradleymeck: how has --disable-proto been going in node |
| 19:32 | <bradleymeck> | npm audit still as noisey as ever |
| 19:32 | <bradleymeck> | same with --frozen-intrinsics |
| 19:33 | <bradleymeck> | optional chaining does remove the need for some helper libs like lodash so may see a long tail decrease |
| 20:03 | <ljharb> | i still don't think most of them are actual vulnerabilities |
| 20:46 | <ljharb> | bendtherules: heads up on one final change on https://github.com/tc39/ecma262/pull/2076 before i land it :-) |
| 21:32 | <bradleymeck> | ljharb: regardless of personal feeling there appears to be a need to fix whatever category of issue is causing the distress |
| 21:33 | <bradleymeck> | I personally do agree it is a vulnerability if you are unable to verify consumers |
| 21:33 | <ljharb> | there's been just as many CVEs caused by catastrophic regex backtracking; why doesn't that need fixing? |
| 21:33 | <bradleymeck> | I never said it doesn't |
| 21:34 | <bradleymeck> | I just am asking about addressing a noisy issue of the ecosystem, redos has owasp coverage and mitigation pretty well documented |
| 21:34 | <ljharb> | sorry, not trying to throw some whataboutism on it :-) i'm just confused why this one is worth trying to "fix" in the language and the other one hasn't been |
| 21:35 | <bradleymeck> | Redos affects other languages and a large variety of tools work to handle it. To my knowledge only ocap styles like SES try to deal with prototype mutation |
| 21:36 | <bradleymeck> | SES doesn't cover entirely the claimed vulnerability since it doesn't seek to prevent codegen entirely |
| 21:37 | <bradleymeck> | Prototype pollution is more JS specific than redos basically |
| 21:37 | <ljharb> | that is a fair point |
| 21:40 | <bradleymeck> | you could also argue that redos doesn't have the same severity, halting execution isn't something JS seeks to prevent generally |
| 21:40 | <bradleymeck> | prototype pollution is about potential codegen/misinterpretation |
| 21:41 | <bradleymeck> | one could prevent progress, but the other can potentially lead towards malicious execution |