2025-12-01 [13:03:27.0662] editor call in an hour? [13:35:08.0877] yep [13:38:06.0702] first order of business today has to be figuring out the VC link in the TC39 calendar invite, since it seems like the Webex link changes every week and becomes stale after use [14:05:46.0450] we're in the webex one, for anyone trying to figure out which call [14:06:23.0336] https://appleinc.webex.com/appleinc/j.php?MTID=m0f74ead98bcea7cb5f86a61bd536989a [15:29:37.0403] okay the future editor call calendar entries should have the new Zoom link [15:30:06.0184] @shuyuguo:matrix.org please delete the calendar invite with the webex link 2025-12-02 [16:51:00.0952] I modified ecmaspeak-py to find violations of the if-command-branches-must-do-the-same-thing convention, found 8. [16:52:33.0493] Actually, on second thought, they're not of the single-line form. [16:53:13.0097] They're all of the form If cond, something. Else, something. [16:56:24.0030] (or "Otherwise") [16:56:36.0806] * (or "Otherwise", for now) [17:12:40.0156] Okay, got it right this time, I think. Found 1 violation, in https://tc39.es/ecma262/#sec-object-environment-records-getbindingvalue-n-s: "If _S_ is *false*, return *undefined*; otherwise throw a *ReferenceError* exception." [17:13:54.0532] But 'throw' is just a shorthand for 'return', so you could say they do the same thing. [17:54:16.0113] hmm, yeah that one seems close enough [18:28:00.0677] Though also could easily be "1. If S is true, throw a RE exception. 1. Return undefined." 2025-12-04 [16:37:48.0881] PerformPromiseAll's abstract closure defines `_index_`, which is also defined outside the closure, which I think was discouraged at some point. Doesn't appear in Editorial-Conventions though. (Abstract closures don't appear at all in Editorial-Conventions.) [17:50:50.0241] yeah, we generally try to avoid shadowing [17:51:12.0680] in this case, we should probably just inline it, since there's only 1 usage site [18:25:26.0020] @jmdyck:matrix.org I opened https://github.com/tc39/ecma262/pull/3732 [18:41:08.0625] I don't love doing `a[b[c]]` [18:41:17.0892] it's obviously legal but we don't usually do that [18:56:48.0121] ecmaspeak is okay with it, dunno about esmeta [18:57:55.0702] esmeta check passed, so i guess it's okay [20:45:45.0218] also ecmarkup seems fine with it [20:46:03.0645] it's highlighting the field properly when I select it [20:46:16.0612] I think it's fine [02:55:47.0146] (internal slot, not field) [09:26:13.0685] same notation, ecmarkup doesn't know the difference [09:29:49.0726] @shuyuguo:matrix.org this PR is just waiting on your review: https://github.com/tc39/ecma262/pull/3009#issuecomment-3611085325 [10:19:07.0135] 3730 has same problem with `_alreadyCalled_` [10:36:43.0619] hmm, I could rename the outer alias in that one, but there's also not much point in the inner alias, so I'll probably just inline that one as well [10:37:48.0515] that alias and the index alias mostly only existed because of those steps' origin as a separate AO, not because it would be how we would write it from scratch [11:24:29.0112] shall we stamp https://github.com/tc39/ecma262/pull/3009 as ready? [13:48:18.0146] I'm curious why [[AlreadyCalled]] is sometimes a Boolean, and sometimes a Record containing a Boolean. (But I doubt I'd understand the answer.) [13:49:23.0881] for PerformPromiseAllSettled, it's shared state for both the onFulfilled and onRejected callbacks [13:49:37.0158] so we make it a record so that both functions share the same value [13:50:46.0009] this doesn't apply to PerformPromiseAll or PerformPromiseAny because those just have a single callback (onFulfilled and onRejected respectively), so they don't need to share that state with anything else [13:51:11.0008] okay, thx 2025-12-05 [07:09:31.0669] https://github.com/tc39/ecma262/pull/3715 is implemented in JSC and SM (not shipping to stable yet in either); should we merge now? It's making an error into a non-error so no web compat risk I think [08:01:32.0570] Is there a rush? I think I might prefer to be cautious and wait to see if V8 runs into implementation difficulties. I don't expect it, but it's possible. [12:42:43.0553] I guess not urgently but normally two impls is enough 2025-12-08 [12:46:16.0587] editor call in ~1.25 hr? [14:00:54.0707] yes, michael and I will be there shortly [14:01:24.0587] Is it the webex link? [14:02:03.0290] no, the zoom link [14:02:13.0582] it should be in the calendar [14:45:13.0796] So the only 'anonymous built-in functions' left are the ones for CreateResolvingFunctions. Are there plans to use ACs for that too? [15:41:30.0819] also https://tc39.es/ecma262/#sec-%throwtypeerror% [15:42:20.0367] and yeah, I should probably replace promise resolve/reject functions with ACs as well 2025-12-10 [23:14:02.0602] bakkot: i think you can log in as tc39-user on npm? if so, it’d be great if you could make a new granular token for that one package that lasts 90 days, and update it in the spec repo secrets [07:13:56.0620] ljharb: I would prefer to merge https://github.com/tc39/ecma262/pull/3706 instead, unless there's a reason not to. You've said it has security issues, which would be a good reason, but I'd like to understand what those are before rejecting that approach. [08:27:33.0866] OIDC tokens can be exfiltrated, allowing an attacker to mint new publish tokens forever and there's no way for maintainers to mitigate it [08:27:50.0199] when github fixes that, then it'll no longer be worse than a 1FA token [08:46:07.0598] OIDC tokens are normally pretty short-lived. Are the OIDC tokens really eternal? That definitely does seem bad [08:46:13.0996] * OIDC tokens are normally pretty short-lived. Are the OIDC tokens in trusted publishing really eternal? That definitely does seem bad [08:49:58.0189] docs definitely claim it is short-lived https://docs.github.com/en/actions/concepts/security/openid-connect#adding-permissions-settings [08:50:16.0832] someone else claims 5 minutes https://github.com/google-github-actions/auth?tab=readme-ov-file#inputs-workload-identity-federation [08:51:04.0879] do you have a specific reason to think that the ODIC token lives forever? I could go to the effort of exfiltrating one and confirm I guess [08:52:16.0698] their sample token in the docs also lives for 5 minutes so that number seems plausible [09:04:01.0845] i'm not talking about the short-lived npm publish token that oidc generates [09:04:12.0001] i'm talking about the oidc credentials THEMSELVES that let you mint infinite short-lived tokens [09:05:08.0347] (that github shouldn't be exposing to the actions workflow, which is the flaw) [09:05:36.0028] this isn't just me, to be clear, this is why the public position of OpenJS is that nobody should use OIDC yet [09:20:15.0154] Is there more about that written somewhere? The only guidance from openjs I can find is talking more about lack of 2fa and manual setup https://openjsf.org/blog/publishing-securely-on-npm [09:24:22.0124] no, the discoverer hasn't published a blog post yet [10:22:34.0413] I think we should go with whatever publicly available guidance we have from trusted sources [10:23:03.0788] if we're really concerned, can't we do something like this temporarily? https://github.com/step-security/wait-for-secrets#publish-to-npm-registry-using-one-time-password-otp [10:24:04.0350] that would be on every single commit though [10:25:21.0842] well they're often batched, so every time Jordan lands a batch of commits, that would be putting a OTP in once for the last one [10:29:12.0552] ljharb: my understanding of the trusted publishing flow is like - the action requests a short-lived JWT from github, signed with their private key (which is global, not per-project) - it sends it to npm, which checks the signature, expiration, and repo+workflow filename - npm sends a short-lived publish token to the action - the action publishes using that token If _github's signing key_ is compromised that's a very big deal. If the JWT is not actually short-lived, or the publish token is not actually short-lived, contrary to the docs, that would allow eternal publishing. but otherwise I don't understand what issue you could be talking about here. leaking the JWT is not a big deal because it expires after five minutes. leaking the publish token is not a big deal because it expires after... however long it is. [10:40:16.0882] Yes that’s what I’m saying, you can exfiltrate GitHub’s signing key [11:05:54.0707] I feel like we shouldn't be having this conversation in a public space [11:06:09.0511] even the existence of such an issue would be very sensitive info [12:14:23.0329] it's long since been discussed in a public space. [12:14:46.0508] btw apparently you can go to https://www.npmjs.com/settings/tc39-user/new and generate a new long-lived classic token, and the token just won't be listed on the tokens page, so that's an option too [12:15:54.0111] * btw apparently you can go to https://www.npmjs.com/settings/tc39-user/new and generate a new long-lived classic token, and the token just won't be listed on the tokens page, so that's an option too (with a nice side of 🤦‍♂️ for the github security folks) [13:08:05.0766] lol so they revoked all existing ones but still allow you to create new ones? 2025-12-11 [14:14:25.0894] looks like they closed that loophole 2025-12-15 [19:18:31.0736] ljharb: I ran some experiments. As far as I can tell there's three tokens involved: the initial ACTIONS_ID_TOKEN_REQUEST_TOKEN, which is valid only for the duration of the run and also expires after 6 hours; the OIDC token with audience `npm:registry.npmjs.org`, which is valid for 5 minutes; and the publish token, which is valid for 15 minutes. none of these values appear to be configurable and all of them are enforced, at least in my testing. [19:19:23.0465] so I think your correspondent is either confused or the issue has been fixed [19:19:54.0129] can you either link me to the aforementioned public space or put me in touch with whoever told you about this? [19:20:43.0304] * ljharb: I ran some experiments. As far as I can tell there's three tokens involved: the initial ACTIONS\_ID\_TOKEN\_REQUEST\_TOKEN, which is valid only for the duration of the run and also expires after 6 hours; the OIDC token with audience `npm:registry.npmjs.org`, which is valid for 5 minutes; and the publish token, which is valid for 15 minutes. none of these timeouts appear to be configurable and all of them are enforced, at least in my testing, which means you can get a maximum of < 7 hours that you can publish by compromising a single run. [19:45:30.0366] yep, I’ll get in touch with him tomorrow. It very likely has been fixed at this point. [13:27:10.0726] i saw michael declined today, @bakkot:matrix.org are you planning on attending today? [13:27:32.0732] yes and I assumed Michael Ficarra was as well, he's online today [13:27:53.0343] possibly he just declined your additional invite? we said we're switching to a consistent zoom call instead of webex [13:28:00.0131] so I don't think we need a weekly invite anymore [13:28:23.0146] ooh [13:28:27.0610] i forgot about the zoom thing [13:28:57.0019] where's the zoom info? did i miss the invite [13:29:58.0210] it's on the TC39 events calendar [13:30:14.0453] link should be stable week to week [13:30:43.0943] i don't see it in my calendar, let me see [13:32:43.0470] huh i guess I have to re-import [13:32:46.0573] anyway i see it now, cool [15:02:41.0088] okay here's what I added for editorial conventions: https://github.com/tc39/ecma262/wiki/Editorial-Conventions/_compare/836aac5fb8679dd3ac93600e6770e9c1e29ece6a...9ac8a2f98aa9711fe82357eb623c4c8977457bfc [15:08:56.0079] so no editor call until Jan 5? [15:10:24.0465] I think Michael Ficarra and I are around and will continue having calls [15:10:26.0680] just no Shu [15:13:58.0629] ok 2025-12-17 [12:43:36.0293] FYI @ljharb:matrix.org the ready to merge PRs are starting to stack up https://github.com/tc39/ecma262/issues?q=sort%3Aupdated-desc+state%3Aopen+label%3A%22ready+to+merge%22 [12:43:40.0699] please take a look when you get a chance [12:44:04.0261] Thanks, I’ll land them all this afternoon [12:44:24.0569] also do we have an update on trusted publishing (https://github.com/tc39/ecma262/pull/3706) yet? [12:45:57.0118] no, i haven’t heard back from the person yet, but i do think it’s likely fixed now. I still think we should stick with a 90 day token for now, since things are still evolving, and revisit oidc in the future 2025-12-18 [10:06:09.0978] Michael Ficarra did you want to review https://github.com/tc39/ecma262/pull/3581 or did you review while rebasing? [10:06:25.0360] if you're happy with it you can stamp it I think [13:46:26.0955] any need to leave that as more than one commit? [13:53:21.0281] no, definitely squash it 2025-12-22 [10:36:48.0890] turns out I can't make editor call today, Michael Ficarra you probably want to cancel [10:37:05.0629] 😞 [10:37:17.0423] fine [13:02:45.0517] ljharb: updated the token secret in CI with a new 90 day token for now; I think we should say that if there are no further developments during that period we switch to trusted publishing when it expires [13:03:51.0532] also I think at some point I got you the tc39-user creds also, in case something happens to me or my devices; lmk if this is not the case and I can send them [13:04:39.0655] also updated the ecma402 one while I was at it (same token, scoped to just those two packages) 2025-12-23 [20:55:56.0289] that seems fair. thanks for the buffer to figure things out. i don’t seem to have the credentials in my password managers. 2025-12-29 [18:32:01.0476] editor call still on for tomorrow? [18:49:43.0186] I'll be around, idk about Michael Ficarra [18:51:46.0550] yep I'll be there 2025-12-30 [10:31:03.0224] rendering for normative optional prose is a bit weird when it crosses multiple lines: https://tc39.es/ecma262/multipage/ecmascript-language-statements-and-declarations.html#sec-block-static-semantics-early-errors [10:31:54.0388] in particular the background color goes all the way up to the baseline of the text on the previous line, so if there's any letters (or, here, a comma) on that line which go below the baseline they get cut off [10:39:21.0964] I think we just need the padding to not apply in either of these cases (ul/ol and inline elements like span) [10:42:34.0369] yeah that sounds right