| 15 Feb 2026 |
 vcunat | Nice for simple version bumps probably, though. | 18:13:48 |
 Grimmauld (any/all) | compression libs do get quite some CVEs for random shit. We call our package sources "trusted", because they are pinned by a hash - a luxury we can not afford before calculating the hash. If hashing itself is an unsafe operation, then things are wrong. And thus i have my doubts about pinned zlib... | 18:15:40 |
 K900 | I mean | 18:16:19 |
| K900 | This is what Yarn upstream does | 18:16:22 |
| K900 | The only other option is regenerate all lockfiles | 18:16:28 |
| K900 | But sigh | 18:16:32 |
| vcunat | At that point we just mark these fetches as insecure? 😅 | 18:17:37 |
| vcunat | * At that point we just mark these fetches as vulnerable? 😅 | 18:17:45 |
| Grimmauld (any/all) | can we just delete JS? /hj | 18:18:12 |
| vcunat | (the "vulnerable" mechanism isn't able to differentiate substituted builds, unfortunately) | 18:18:30 |
 emily | they'd be the same to write | 18:19:22 |
| emily | staging and staging-next would always have the tree after cleanups for the relevant epoch | 18:19:52 |
| emily | so you just work on that branch and run the script to produce the form that goes to master as a commit on top | 18:20:26 |
| vcunat | I missed the script. See it now. | 18:20:38 |
| emily | essentially a merge of staging/-next back into master | 18:20:38 |
| emily | it'd suck to touch stuff being staged on master, but that's the thing that sucks now and the suck gets externalized to people doing manual merge :) | 18:21:16 |
 Lun | nixpkgs, now with federated suck processing technologyâ„¢ | 18:22:12 |
| emily | there's a lower-tech variant where you have no conditionals in the code but every staging/-next PR has a HEAD that merges it back into master to undo the changes, and merge queue just validates no conflicts/eval errors across the branches. that makes merging -next into master weird from a Git POV though (it would produce a nop by default because "all the changes are already merged in").
or the reverse is that if you have to do something to resolve conflicts between master and staging/-next you keep your commit based on master but add a merge commit merging it into staging/-next and the master portion of it just gets automatically backported.
those avoid any eval time machinery but abandon the property that there's one canonical tree that lets you see when stuff is in flight before you touch it. they would also interact a bit weird with the way GitHub displays merge commits and require CI to have more smarts around them
| 18:27:30 |
| emily | the latter option does have the perk that it's exactly the same merge structure we have now and just distributes the work of doing the conflicting ones to the authors of the PRs that cause the conflicts | 18:29:07 |
| emily | (but it punts on helping with the conditionalization dance except insofar as it makes it easier to land the conditional and the clean-up in the same PR without one getting forgotten) | 18:31:01 |
| emily | also with the feature flags variant we could still have the "controbutor didn't realize this needs staging, let's retarget with a couple clicks" convenience by having CI detect PRs targeting a staging branch, automatically push the generated staging commit, and retarget back to master | 18:33:34 |
| emily | which also means that if you're doing a simple non-conflicting staging change you don't need to run any script locally at all and can just send a PR to staging as you do now | 18:34:02 |
| emily | the script doesn't have to be perfect because it's just a convenience and doesn't have to be in the trusted code base, it can get away with just handling the common cases | 18:35:18 |
