| 27 Nov 2024 |
 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 |
| emily | I just wanted to flag up that there is going to have to be actual substantial design and implementation work to make it work for Darwin :) | 06:43:22 |
| John Ericson | I was very pleasantly surprised how good crowd-sourcing cross support went | 06:43:34 |
| emily | I think that work will make things better as a whole because it lets you handle other edge-cases and brings other non-CA benefits to Darwin, but – it's still work | 06:43:46 |
| John Ericson | In reply to @emilazy:matrix.org
I just wanted to flag up that there is going to have to be actual substantial design and implementation work to make it work for Darwin :) yes and thanks for doing so! | 06:43:47 |
| John Ericson | In reply to @Ericson2314:matrix.org
I was very pleasantly surprised how good crowd-sourcing cross support went So I am just curious how far we can get patching things to avoid self-references if it is properly gamified, etc. | 06:44:31 |
| John Ericson | if we wait for elaborate workarounds (which I know you aren't proposing) we'll never find out | 06:46:01 |
| emily | my sense is that it will cause far more pushback than cross b/c far less immediate tangible benefit, far more invasive patching in some cases, and things that don't work with cross are considered in some sense broken whereas self reference is not so obviously illegitimate | 06:48:20 |
| emily | also b/c making sure everything is fixed to absolute paths is very long-standing Nixpkgs convention and this turns that on its head | 06:48:43 |
|  andiandi 🐈 changed their display name from andiandi to andiandi 📞 4690@38C3. | 11:04:01 |
| andiandi 🐈 changed their display name from andiandi 📞 4690@38C3 to andiandi 📌 38C3 📞 4690. | 11:05:02 |
| John Ericson | Otoh people will be really excited about being able to unzip something in their home directories and it just works | 14:59:16 |
