Nix Milan | 107 Members | |
| https://milano.nix.pizza/ | 7 Servers |
| Sender | Message | Time |
|---|---|---|
| 24 Oct 2025 | ||
| Qualcuno al Linux day domani? | 18:02:23 | |
| Ottimo! | 19:10:08 | |
In reply to LucioSi e secondo me saremo almeno almeno 3-4 da questo gruppo | 19:05:43 | |
| 25 Oct 2025 | ||
In reply to Andrea CiceriCome fa l'umile omettendo che deve fare un talk su NixOS | 03:28:22 | |
| Però ci sta imo, soprattutto per CI oppure setup dichiarativi | 08:00:55 | |
| Lmao | 08:00:19 | |
| @Mugiwarix https://git.m-labs.hk/M-Labs/wfvm | 07:59:26 | |
| 12:38:03 | ||
Download image.jpeg | 12:25:02 | |
| Buon Linux day a tutti | 12:25:02 | |
| 13:14:37 | ||
| 16:42:50 | ||
| Non ho mai usato agenix o similari ma mi viene un dubbio: ho una derivazione che per essere buildata richiede un segreto. C'è modo di far sì che uno possa usare la derivazione prendendola da una cache binaria, anche se non sarebbe in grado di rebuildarla perché non ha accesso al segreto? | 19:59:45 | |
In reply to geckoQuindi tipo che il compilatore ha bisogno di una password per funzionare? In un caso simile, il binario andrebbe senza password, quindi basterebbe copiarlo altrove e funzionerebbe. Se invece anche il binario ha bisogno di quella password per funzionare, allora no. Ma mi pare di capire che il secret ti serva solo in fase di build, quindi direi che basterebbe fare la chiusura del pacchetto e lo potresti far andare ovunque. | 22:28:03 | |
| Credo che serva un metodo per introdurre il segreto in una maniera impura durante la build, per fare in modo che non venga messo nella closure che ti copi quando vai a prendere la derivazione dalla cache | 22:49:29 | |
In reply to geckoProva a dare un'occhiata all'opzione allow-unsafe-native-code-during-evaluation e builtins.exec (che è abilitato solo se quell'opzione è true) magarihttps://nixos.wiki/wiki/Comparison_of_secret_managing_schemes | 22:50:59 | |
| 26 Oct 2025 | ||
| Ma agenix come funziona? La chiave privata non finisce nello store quindi da un certo lato è "impuro". Pensavo di poter sfruttare il modo in cui fa le cose agenix. | 07:26:31 | |
Lo script eseguito come activation script si aspetta che l'host abbia le chiavi ssh giuste per decriptare i segreti ma non puo' saperlo quando nix valuta e builda le derivazioni. Quindi magari il sistema parte e tutto pero' mancano i segreti dentro /run/agenix e i servizi che li cercano falliscono quindi | 14:39:07 | |
| https://github.com/tweag/rfcs/blob/acls/rfcs/0143-nix-store-acls.md C'e' questa RFC in proposito comunque | 14:43:03 | |
In reply to geckoagenix e' sia un modulo NixOS che una utility CLI: - la CLI ti permette di manipolare i segreti ( agenix --edit foo.age)- il modulo NixOS ti permette di dichiarare quali sono questi segreti (specifichi quali sono i file .age che quindi verranno copiati nello store) e aggiunge un activation script a NixOS che prova a decriptare questi file .age (tipo in /run/agenix/foo). Inoltre sempre dichiarativamente ti lascia specificare i permessi che avranno i file decriptati e ti lasciare sapere ad eval time di nix quali saranno i path dei segreti cosi' che tu possa settarli dentro altre opzioni (services.pippo.tokenPath = config.age.secrets.foo.path) | 14:37:51 | |
| Comunque, per curiosita', che derivazione stai buildando a cui serve un segreto? Magari c'e' un modo piu' pulito di gestire la cosa. Altrimenti concordo con @steinuil, non credo si possa fare altro... Perche' comunque va bene introdurre una impurita' nella sandbox per leggere il segreto ma poi l'output finale nella derivazione non contiene piu' in nessun modo il segreto? Chiedo perche' senno' cosi' sei da capo | 14:42:47 | |
| Se non ho capito male lui vorrebbe fare in modo che uno possa sostituire la derivazione tramite la cache (quindi gli input sarebbero uguali?) ma se non hai il segreto non puoi buildarla | 14:54:01 | |
In reply to FrancescoSe ho capito bene: - hai il segreto -> buildi tutto da solo (impuremente, il segreto non finisce nello store) - non hai il segreto ma hai la cache configurata -> la scarichi dalla cache (e comunque il segreto non finisce mai nello store) Pero' mi chiedevo che cosa ncessiti di segreti durante la build che poi non vengano in qualche modo propagati nell'output. Forse deve firmare dei binari? | 15:13:41 | |
| 27 Oct 2025 | ||
| Il segreto non deve finire mai in chiaro da nessuna derivation chiaramente, questa è la cosa importante. Per quello pensavo di usare agenix. Se agenix me lo mette in una qualche path noto fuori da /nix/store o in una variabile d'ambiente a me va bene, poi m'arrangio. | 14:40:39 | |
In reply to Andrea CiceriNon mi è chiaro come funzioni l'"activation script", ma mi pare che alla fine l'assenza delle chiavi SSH sia un'impurità che in questo caso giocherebbe esattamente a mio favore. Nel senso che il fatto che tu la abbia o no non finisce nell'hash della derivation. | 14:39:13 | |
In reply to Andrea CiceriDiciamo che ho un """compilatore""" closed di cui pago la licenza. Io vorrei che la CI lo possa usare, ma gli utenti no. Gli utenti devono però essere in grado di tirare giù dalle cache binarie delle derivation che hanno usato quel compilatore. | 14:37:10 | |
| ma il compilatore deve avere il segreto nella derivation o può leggerlo da una variabile d'ambiente o da un file fuori dal nix store? | 14:39:41 | |
Sì ma popolare a mano il nix store fa schifo :P | 14:52:40 | |
| Come no? | 14:49:53 | |
| @gecko4242 metti un attimo da parte nix. come faresti senza? Se il segreto può essere messo in una variabile d'ambiente e ti serve in CI, usere lo strumento della CI | 14:44:42 | |