| 27 Nov 2024 |
 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 |
| emily | I agree, that's a good idea | 06:43:08 |
| John Ericson | but because incentives | 06:43:09 |
