| 25 Nov 2024 |
 emily | in e.g. remove-references-to | 20:40:33 |
 p14 | Yeah, I thought so too, but I had some issues. I may not have hit it with the stick hard enough. | 20:40:47 |
| emily | you might also want to add an example of a build tool that depends on a library, to screw all the nice properties up | 20:40:54 |
| p14 | Well yeah; that's going to be the interesting/unfortunate case. I was thinking of that in the context of 'glibc' upgrades. ISTM that if you have to relink users of glibc, this means relinking the compiler, which then means everything that uses the compiler has to be rebuilt. | 20:41:38 |
| emily | yes | 20:42:05 |
| emily | the alternative is letting buildPackages drift etc., which isn't fun | 20:42:21 |
| emily | ultimately compiler upgrades are compiler upgrades. what I worry about is more, like, random build stuff that has OpenSSL dependencies | 20:42:43 |
| emily | for hashing or because it has network functionality we don't use or – whatever | 20:42:51 |
| p14 | So I was wondering about how you could make stdenv.mkDerivation do what the gist above does under the hood. Perhaps by modifying how getDev works; I think this would be enough to handle buildInputs. Then you'd need some way to make packages 'be observed as' the relink. | 20:44:42 |
| p14 | Any bright ideas about where such logic could hide? | 20:44:54 |
| emily | it's basically splicing in miniature I think. | 20:46:10 |
| emily | the hard part is making relinking happen. | 20:46:21 |
| p14 | That's about where I was up to :) | 20:46:24 |
| p14 | Another thing I was wondering about was the eval cost of all of this, and whether that is an issue or not (for the likes of ofborg). | 20:47:03 |
 trofi | In reply to @Ericson2314:matrix.org
trofi: I think it can go directly to master, no? Good catch! Updated as https://github.com/NixOS/nixpkgs/pull/359098#issuecomment-2499050124 (don't know why I did staging last time, possibly because the initial change I had to mitigate was introduced in staging) | 21:31:08 |
| 26 Nov 2024 |
|  Salar Rahmanian (softinio) joined the room. | 18:15:37 |
| 27 Nov 2024 |
| emily | John Ericson: re recent ca-derivations posts, you're aware that as of present it breaks aarch64-darwin basically entirely right? | 02:42:56 |
| emily | (I assume there is no obstacle to rolling it out for Linux only, and there are things that could be done to fix the incompatibility with engineering work, but I just wanted to check that you know this) | 02:43:16 |
| emily | (happy to discuss more) | 02:43:39 |
 John Ericson | @emilazy:matrix.org: err nope I'm not aware of this | 02:44:52 |
| emily | ok. so on aarch64-darwin, every binary must include a code signature or it won't start up. we use "ad-hoc signatures" for everything at present, which is what you get by default when running a compiler and is basically just an SHA-1 hash | 02:46:05 |
| emily | every time a binary is rewritten it must be re-signed, which all the basic tools (install_name_tool which is like macOS patchelf etc.) do out of the box | 02:46:28 |
| emily | therefore rewriting binaries for CA self-references breaks them | 02:46:37 |
| emily | three possible solutions, of increasing elegance and decreasing layer violations
- Nix detects when it's poking at an
aarch64-darwin binary – regardless of host platform! – and re-signs it after rewrite (so, Nix unconditionally links to rcodesign or similar I guess). and the code signature part of binaries is excluded from the content hash
- we put a manifest in
nix-support listing files that are executables that need re-signing and (ditto) – this at least gives stdenv flexibility to get policy here even if we do the same sniffing by default
- we put a more elaborate manifest in
nix-support listing files that need some kind of post-processing after rewriting and what tools to run on them and how to determine which parts of them should be excluded from the hash. this could also handle things like updating .zip checksums or whatever. but you could do things to "break the model" here of course, and it's not clear what the best format would be or how much flexibility you'd need
| 02:49:36 |
| John Ericson | In reply to @emilazy:matrix.org
therefore rewriting binaries for CA self-references breaks them ah ok emily I thought you meant the recent nixpkgs stuff | 06:36:32 |
| John Ericson | emily: my actual plan is simply to have have self references :D | 06:36:46 |
| John Ericson | I want "core" nixpkgs pkgs to be (a) no self references (b) relocatable, no /nix/store before any store path <asdfasdf>-<name> that's a reference | 06:37:36 |
| John Ericson | (you can have /nix/store/asdfasdf-nix if it's just a made up path that's not a reference, like the ones in the nix manual --- I wouldn't want to make the manual illegal) | 06:38:01 |
| emily | my point is that every aarch64-darwin binary essentially has a self-reference | 06:38:11 |
| emily | I mean, I guess it only actually breaks when you rewrite self-references | 06:38:28 |
