2025-10-03 [14:41:59.0678] does anyone care to review https://github.com/tc39/ecma262/pull/3698 or should I just stamp it [14:58:38.0495] merge it 2025-10-13 [12:56:29.0859] dang it, completely forgot again [14:02:45.0566] jmdyck: we're gonna move it two hours later, hopefully that will be a better time [14:18:27.0836] probably better for me. starts next week? [15:22:10.0080] yes [15:22:24.0258] the calendar event should already be updated 2025-10-15 [08:50:48.0797] is there a good reason why we don't have `?` and `!` appearances link to their definition? [08:50:56.0808] it's really not easy to Ctrl+F for [08:58:57.0110] could probably be done [08:59:09.0699] not sure if the existing autolinking would handle it, particularly avoiding false positives [09:42:30.0989] we could use an alternative notation in the spec document [09:42:40.0281] it doesn't *have* to look like `?` and `!` in the source [09:42:50.0410] * we could use an alternative markup in the spec document [09:44:32.0266] No, absolutely not [09:44:53.0659] That is an unreasonable burden on authors [09:53:32.0383] do you think it would add much weight to the rendered document? [09:53:36.0618] that's a lot of links [09:56:20.0120] I assume it compresses though it does still affect parse and layout [09:57:02.0507] Striiiictly speaking we could do it client side [09:57:36.0831] Ecmarkup could be made to be client side entirely [10:22:19.0942] lol I (selfishly) care more about weight for initial rendering time, not download time, so that would work against my goals 2025-10-16 [14:08:54.0639] more meta stuff https://github.com/tc39/ecma262/pull/3706 [14:41:42.0628] I am going to assume shu does not care to review this and stamp it as ready 2025-10-20 [09:55:57.0852] ljharb: can you say more about what's worse with trusted publishing than our current setup? [09:56:04.0350] possibly at editor call if that would be easier [09:58:44.0201] I’ll pop in and disclose, sure. either way tho it wouldn’t be any more secure, even if the flaw I’m referring to was addressed [10:30:56.0037] ... wouldn't it? right now compromise of the publish job would allow an attacker to exfiltrate the token, which gives persistent access to publishing until the token is revoked, and would allow publishing all packages controlled by the tc39 user. with trusted publishing, assuming we remove the secret, it only gives one-off access and only to the one package [12:05:03.0945] we can switch it to a granular token, so at least it’d be only that package. but even in a properly functioning oidc setup it’s single factor. so in that scenario we could set up an environment that requires a second approval, and then it’s actually two factor, making it safer. (but GitHub’s impl is broken) [12:05:57.0708] nobody’s in the call, but tldr the flaw (via an exploited workflow) allows for permanent issuing of new tokens and there’s nothing package owners can do to stop it. [12:06:12.0528] call moved to 2pm, sorry [12:07:49.0875] I agree that if there was a second factor in our current setup then that would be more secure than trusted publishing, but there isn't [12:08:14.0891] so as it stands, from what I can tell, trusted publishing is more secure than our current setup [12:08:29.0132] except for this flaw you describe [12:09:44.0136] also I am not interested in setups where there's a second factor required to publish the biblio, I want it to be automated and run on every commit with no manual intervention [12:12:15.0392] sorry about the meeting timing, I thought michael had updated the calendar invite but that must have been something else [13:08:46.0154] meeting in 51min? [13:42:44.0766] Yes 2025-10-21 [15:49:09.0429] is it moved to 2pm every day or just this once? [15:49:53.0785] trusted publishing isn’t any more secure than our current setup, which is also one factor. It’s equally as secure module the flaw i described. [16:00:20.0378] every day [16:01:11.0919] I described above why I think trusted publishing is more secure than our current setup: > right now compromise of the publish job would allow an attacker to exfiltrate the token, which gives persistent access to publishing until the token is revoked, and would allow publishing all packages controlled by the tc39 user. with trusted publishing, assuming we remove the secret, it only gives one-off access and only to the one package what part of that do you think is false, or do you not think that constitutes "more secure" for some other reason? [16:03:11.0743] though also to be clear I don't actually care much about the minor difference in security, just that this will continue to work next month after github disables existing non-granular tokens, and that it does not require manually rotating tokens 2025-10-22 [10:18:00.0259] shu: I added the bit about ephemerality to https://github.com/tc39/ecma262/pull/3705; did you want to do a full review or should I stamp it now that Michael has approved? [12:17:57.0126] I’ll answer in more depth later but it’s getting more likely GitHub won’t follow through with their disastrous plan as-is, so i don’t think we have to worry [12:47:04.0818] @bakkot:matrix.org remember to [add to the editorial conventions](https://github.com/tc39/ecma262/pull/3705#issuecomment-3407162384) following the merge of that PR [12:47:21.0427] yup [14:30:12.0752] interesting https://github.com/tc39/proposal-temporal/pull/3167 [15:14:22.0121] oooo 2025-10-27 [07:21:37.0191] The editor call on the TC39 calendar is still showing as noon Pacific, but I have a separate personal invite from Shu for 14:00 Pacific. I'm assuming the later time is the correct one. We should update the TC39 calendar. [14:55:37.0747] shu: stamping https://github.com/tc39/ecma262/pull/3711 as ready without your review on assumption you don't want to review minor tweaks to the module machinery 2025-10-31 [12:39:58.0665] esmeta parsing/stringifying has been significantly improved: https://github.com/es-meta/esmeta/pull/316 > With above changes, the number of equal algorithms has increased to 2,655/2,867 (92.61%) from 1,357/2,852 (47.58%). [12:42:16.0051] this should reduce the noise we were concerned about in editor call last month when considering having a CI warning about newly-introduced phrasing: https://github.com/es-meta/esmeta/pull/302#issuecomment-3471949573 [12:42:28.0373] let's discuss again next editor call