 | Nix Milan | 115 Members |
| https://milano.nix.pizza/ | 9 Servers |
| Nix Milan | 115 Members |
| https://milano.nix.pizza/ | 9 Servers |
| Sender | Message | Time |
|---|---|---|
| 2 Mar 2026 | ||
 Lucio | Direi che abbiamo un argomento per la prossima conf 😄. Magari creiamo anche una PoC. | 07:11:18 |
 gecko | Il punto è che, come admin, non puoi accettare richieste dai tuoi utenti di aggiungere cache di terze parti perché è una cosa che ha un effetto non-locale (e in particolare, anche su root). E questa cosa non è ovvia, è subdola. Intuitivamente uno potrebbe dire "beh, mal che vada mi installa del software che usa solo lui, è già quello che succede normalmente", invece no, le cache sono più pericolose perché non c'è modo di verificare che quello che ti offrono è quello che ti dichiarano di offrire. Ma soprattutto dato che lo store è uno per tutti, questo affligge tutti gli utenti del sistema. Dato che uno dei design di nix è quello di permettere a qualsiasi utente di installare il software che vuole, senza chiedere all'admin, questa è una limitazione. Come dico, infatti, han cercato di mettere in piedi una soluzione con i layered store. Più pragmaticamente, io voglio offrire una cache per un mio flake, ma è per me un problema avere la liability di poter pushare una versione backdoorata di sudo. In quanto utente, io non la userei. In quanto maintainer della cache, non voglio questa responsabilità. > E centrare la hash del sudo di chi farà lo switch del sistema è un bel terno al lotto Non direi, basta anticipare la patch per aggiornare sudo su nixpkgs e poi fare esattamente quello che fa hydra. Non c'è *niente* di probabilistico. A seconda di come avviene il packaging della tarball di sudo, potresti anticiparlo addirittura prima che la rilascino. Inoltre, puoi fare quanti tentativi di variazioni vuoi. Anzi, a dirla tutta, potresti servire qualsiasi richiesta per *-sudo-* e dare indietro una versione backdoorata, quindi è proprio semplicissimo. | 10:12:52 |