| 29 Jul 2025 |
emily | which would result in libarchive creating a file like /private/tmp/nix-build-libarchive-3.8.1.drv-6tar.md.CvYd75, which is fine because the permissions are less locked down. comedy | 17:00:17 |
raitobezarius | In reply to @emilazy:matrix.org (I mean it is an upstream bug) what is upstream here | 17:04:45 |
emily | libarchive | 17:04:53 |
raitobezarius | ah ok | 17:04:56 |
emily | and maybe anything else similarly dumb | 17:04:59 |
emily | it's not worth worrying about I think | 17:05:06 |
emily | given it would cause issues on Linux too (it was in a macOS-only code path in this case), and was already behaving wrong pre-CVE-fixes | 17:05:29 |
emily | FWIW something seems screwy about Unix sockets in /tmp in the Darwin sandbox even after fixes: https://github.com/NixOS/nixpkgs/pull/429415 | 17:30:12 |
emily | but I'm not sure exactly what/how | 17:30:21 |
emily | and it may be an okay regression because we should really be closing that off anyway… | 17:30:32 |
raitobezarius | i cannot understand what is screwy | 17:31:21 |
raitobezarius | what behavior do you see | 17:31:27 |
raitobezarius | ah you're not exactly sure neither | 17:31:38 |
emily | bind fails on /tmp/blah | 17:34:40 |
emily | I don't know, libuv regularly breaks in the Darwin sandbox, so maybe it wasn't related to the CVE stuff | 17:35:07 |
emily | but it seems suspicious (but I can't figure out why it'd have become screwier) | 17:35:18 |
emily | Redacted or Malformed Event | 19:02:32 |
emily | Redacted or Malformed Event | 19:02:45 |
emily | Redacted or Malformed Event | 19:03:03 |
emily | (my bad, my own dev env was messed up :P) | 19:05:32 |
raitobezarius | awesome work, thanks emily! | 19:59:09 |
emily | don't test me, I might remove more things from the packaging 😈 | 19:59:48 |
raitobezarius | nix develop --phase testPhase emily | 20:01:42 |
emily | fwiw, I'm happy to re-add the flag for https://gerrit.lix.systems/c/lix/+/3833/5. but since internal-api-docs apparently takes 32 seconds on CI, I think it would only be for closure, not for build speed | 20:02:53 |
emily | and the closures of doxygen and rapidcheck are small | 20:03:47 |
emily | hmmm | 20:14:20 |
emily | I notice that the derivation in Nixpkgs already did this devdoc stuff and I just wasted a non-trivial amount of time :) | 20:14:37 |
emily | is there no systematic sync between those two? | 20:14:44 |
emily | I'll leave what I have up since it's an improvement over HEAD, but it seems like it would be good to minimize the drift between those two to avoid redundant work. | 20:16:09 |
Marie | hi, I do a applyPatches thing to apply PR's to my nixpkgs and I've been getting really annoyed that lix copies nixpkgs into the store on every invocation, even though it is already in the store.
From googling around this seems to be a known issue. If I call my patched thing "source" the problem goes away.
Does anyone know if there is a good reason to only allow "source" here: https://git.lix.systems/lix-project/lix/src/commit/93acdd40f6c3eab1a25ea03d7a160433ed551677/lix/libfetchers/path.cc#L138 | 21:57:17 |