| 27 Nov 2024 |
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 |
John Ericson | yeah, I mean make it so there is nothing to rewrite | 06:38:36 |
John Ericson | rewriting is a bad hack | 06:38:44 |
emily | sure. I would like a relocatable store. I have put thought into it | 06:38:53 |
emily | you need to write your own Linux startup code, which is fun. | 06:39:01 |
John Ericson | can't we just do $ORIGIN? | 06:39:15 |
John Ericson | in rpath? | 06:39:18 |
emily | doesn't work for the ELF interpreter. | 06:39:21 |
emily | so you need your own bootstrap startup code to load a relative ELF interpreter. | 06:39:38 |
John Ericson | mmm | 06:40:01 |
John Ericson | well, how much breaks if we use FHS interpreter heh | 06:40:12 |
John Ericson | it can still be the right thing within builds thanks to namespacing | 06:40:21 |
emily | well, you'd break nix-ld for one thing | 06:40:39 |
emily | anyway I don't think relocatable store is practically achievable in Nixpkgs – we were just talking about glibc relying on self-reference and having a circular dependency with bash etc.; it's a nice moonshot idea but it would break so, so many packages and require quite extensive patching | 06:40:45 |
emily | certainly deploying ca-derivations for aarch64-darwin could not depend on that, I think, unless you want to delay it for years :) | 06:41:11 |
John Ericson | does the signature have to be adjacent? | 06:41:40 |
emily | my preference is for (3) because I want Hydra to be able to do actual full-blown macOS code signing, and making that solution work would pave the way towards that | 06:41:44 |
emily | which would allow us to ship macOS GUI apps to users that don't have scary warnings on startup and can use functionality gated on entitlements that we currently have no way of delivering | 06:42:05 |
emily | In reply to @Ericson2314:matrix.org does the signature have to be adjacent? the hash (or signature) is embedded directly in the executable | 06:42:25 |
John Ericson | OK | 06:42:32 |
emily | in particular (3) is nice because it applies even when there's not rewriting going on | 06:42:55 |
John Ericson | tbh I would ship linux-only CA first | 06:42:59 |
emily | it's a generic solution that happens to help solve the rewriting problem | 06:43:01 |
John Ericson | not cause I hate mac | 06:43:04 |