| 04:52 | <bakkot> | what do y'all figure the odds are that we could make Object.assign special-case __proto__ to not trigger the setter on Object.prototype |
| 04:52 | <bakkot> | probably not high, I guess |
| 04:52 | <bakkot> | but I would like that |
| 04:52 | <bakkot> | (not trigger any setters on Object.prototype, ideally.) |
| 13:22 | <littledan> | huh, are you seeing a particular sort of injection attack occur? |
| 13:22 | <littledan> | or like where is this coming up? |
| 13:24 | <littledan> | Oh this is what everyone is talking about for "secure" JSON parse? |
| 13:51 | <bakkot> | littledan: yeah |
| 13:53 | <bakkot> | some actually exploitable issues, for a change, e.g. https://github.com/advisories/GHSA-p6h4-93qp-jhcm |
| 13:54 | <Jack Works> | what do y'all figure the odds are that we could make |
| 13:54 | <bakkot> | also just a violation of expectations, really |
| 13:54 | <Jack Works> | Oh I don't know if SES is removing __proto__ accessors |
| 14:07 | <littledan> | so this is entirely avoided by Object spread right? |
| 14:07 | <littledan> | what do y'all figure the odds are that we could make |
| 14:08 | <littledan> | at this point I guess we could agree that Object.assign should've had {... } semantics |
| 14:08 | <bakkot> |
yup |
| 14:10 | <bakkot> | though I guess there are still some cases where you want to mutate rather than making a new object, and spread doesn't help there |
| 14:15 | <littledan> | right, but we kinda should've done the other aspects of spread semantics, but it's too late now |
| 14:15 | <littledan> | yeah the small patch sounds like a good approach to me |
| 14:19 | <bakkot> | there's still going to be bugs with manually copying properties, which happens pretty often, but this would be an improvement at least |
| 14:26 | <bakkot> | looking in a little more detail https://arxiv.org/pdf/2207.11171.pdf reports one object.assign issue (linked above) and then two manual copying issues, both in the npm cli (patches for which are https://github.com/angus-c/just/blob/66b8abacba16fff2f16a61620ddaddbcad092349/packages/collection-diff-apply/index.js#L109-L113 and https://github.com/npm/parse-conflict-json/blob/6de41ffe0715cedcd92840e7b463b965461d6235/lib/index.js#L92-L94 ) |
| 14:27 | <bakkot> | can't do much about the manual copying cases, though |
| 14:34 | <littledan> | Do we have any evidence that this error is common? |
| 14:43 | <bakkot> | the object.assign one in particular? not that I'm aware of |
| 14:45 | <bakkot> | JSON.parse in particular? also not that I'm aware of. a lot of exploitable prototype pollution issues in practice come from other sources, notably parsing+copying of query parameters |
| 14:46 | <bakkot> | there are, unfortunately, a distressing number of ways one might end up copying properties from one object to another |
| 14:46 | <bakkot> | we do have evidence that prototype pollution in general is something which is common, though, I think. |
| 14:46 | <littledan> | can we file a CVE to instruct everyone to give up and switch to Python? merging dictionaries and objects seems like a mistake |
| 14:47 | <bakkot> | if only |
| 14:48 | <bakkot> | original sin was having Object.prototype in the first place |
| 14:49 | <bakkot> | and also accessors |
| 14:49 | <bakkot> | a massive sin in combination, also each a sin in isolation |
| 14:51 | <littledan> | also mutable prototypes, instead of Object.create |
| 16:01 | <ptomato> | snek: installation of graaljs in esvu seems to be breaking, you asked for a heads up if that happened again :-) |
| 16:02 | <ptomato> | https://app.circleci.com/pipelines/github/tc39/test262/4173/workflows/ac21cfed-4152-496a-962d-a0d6d24649fe/jobs/38890 |
| 16:05 | <snek> | oh is that |
| 16:05 | <snek> | outdated esvu? |
| 16:06 | <snek> | yeah it is |
| 16:06 | <snek> | should be 1.2.9 but thats 1.2.8 |