| 27 Nov 2024 |
 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 |
| John Ericson | no self references is less work, but relocatable / store dir agnostic is big payout | 15:02:00 |
| John Ericson | * no self references is less work, but relocatable / store dir agnostic is bigger payout | 15:02:23 |
 matthewcroughan | 
Download IMG_20241126_212855.jpg | 15:35:36 |
| matthewcroughan | I was wondering why my router kept going down. | 15:35:45 |
| matthewcroughan | Can't garbage collect without OOMing | 15:36:00 |
 Martin Schwaighofer | In reply to @emilazy:matrix.org
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
I think there is one other solution we can consider, which also enables central signing and does not break any of the guarantees users expect from Nix. I looked into this in 2022, and presented the results at NixCon (https://youtu.be/-CUa3yVTK5U, and https://talks.nixcon.org/nixcon-2022/talk/JHVF8N/). What I found is that if you put building, signing and signature verification into their own CA derivations, you do not have to trust the signing derivation at all. You could consider the signature verification derivation a derivation that either returns one of its direct dependencies or fails, or you could consider it a 'quasi derivation' a la https://github.com/NixOS/nix/issues/11955. The only additional thing you REALLY need in Nix for this is a way to completely prevent rewriting for specific inputs of a specific derivation (if we end up having it) because verification cares about the actual bits and it would be nice to have an officially supported way of annotating this verification relationship in the language (or maybe 'quasi derivations' ... have to think about it) - back then I just used environment variables for this which also works. | 16:01:16 |
| Martin Schwaighofer | In reply to @emilazy:matrix.org
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 Actually what I wrote in my previous message is an alternative way to get code signing to work centrally, I am not sure if it would improve the self reference situation. 🤦♂️ | 16:29:55 |
| 28 Nov 2024 |
 @enzime:nixos.dev | is there a reason https://nix.dev/manual/nix/stable/ points to 2.18? | 01:48:35 |
| @enzime:nixos.dev | should it be pointing to 2.24? | 01:49:15 |
|  sheeeng joined the room. | 07:45:19 |
 Robert Hensing (roberth) | In reply to @enzime:nixos.dev
is there a reason https://nix.dev/manual/nix/stable/ points to 2.18? fricklerhandwerk? | 09:22:54 |
| Robert Hensing (roberth) | In reply to @enzime:nixos.dev
is there a reason https://nix.dev/manual/nix/stable/ points to 2.18? * maybe fricklerhandwerk knows or could solve it | 09:23:28 |
 infinisil | nix.dev has pins that need to be updated | 09:23:46 |
| infinisil | In reply to @enzime:nixos.dev
is there a reason https://nix.dev/manual/nix/stable/ points to 2.18? See https://github.com/NixOS/nix.dev/blob/master/CONTRIBUTING.md#updating-reference-manuals | 09:25:04 |
| infinisil | Although, it might only change once the new NixOS is released, check out https://github.com/NixOS/nix.dev/blob/master/nix/releases.nix for the logic behind it | 09:27:42 |
 fricklerhandwerk | In reply to @enzime:nixos.dev
is there a reason https://nix.dev/manual/nix/stable/ points to 2.18? Also see here for what users should see: https://nix.dev/reference/nix-manual | 09:30:08 |
| emily | that page has "Shipped with the previous stable release" but I thought the support policy was that only the latest version + the version in stable NixOS were supported? so isn't that going to be pointing to the manual for an unsupported version soon? | 09:36:25 |
