 | Nix Milan | 115 Members |
| https://milano.nix.pizza/ | 9 Servers |
| Nix Milan | 115 Members |
| https://milano.nix.pizza/ | 9 Servers |
| Sender | Message | Time |
|---|---|---|
| 1 Mar 2026 | ||
 Andrea Ciceri |  Download Vedo questo, anche io mi aspettavo di vedere le e-mail (comunque l'iscrizione "anonima" con sola e-mail l'ho abilitata io, ma mi sembrava carino non obbligare la gente a creare una utenza) | 14:26:22 |
| Andrea Ciceri | Mi sa che passiamo a luma la prossima volta (pero' non e' open 😢) Non credo verranno 50 persone proprio questa volta | 14:29:20 |
 Nonno Felice | Come workaround semplicemente per dimostrare di essere iscritti si può usare la mail di conferma dell'iscrizione | 15:02:31 |
 Tonio Gela | Che palle mi sono appena reso conto di dover annullare, mi sono scordato che sono via l'intera weekend 😭 | 15:31:41 |
| Tonio Gela | Dovresti vedere l'iscrizione annullata Andre | 15:32:42 |
 Lucio | Non c'è qualcosa di self-hostabile open? | 15:45:32 |
| Lucio | Vedo che Mobilizon è gia self-hostabile e open, magari va tunato solo.un po' | 15:49:13 |
 Edoardo Piccolotto | Iscritto 😊 | 18:37:12 |
| Andrea Ciceri | eh ma e' falsificabile, ci voleva una ricevuta verificabile o qualcosa del genere | 19:15:48 |
| Andrea Ciceri | si, e' anche federato mi sembra di capire, quindi in teoria potete iscrivervi all'evento anche se il vostro utente vive su un'altra istanza | 19:17:00 |
| Nonno Felice | Hai paura che la CIA si imbuchi al meetup? | 19:23:56 |
| Lucio | Intendi il Comitato Internazionale di Ansible? Quelli fanno paura 😄 | 19:32:34 |
 gecko | Il fatto che un hash sia "crittografico" non ha nulla a che vedere con la sua predicibilità. L'hash della derivazione lo puoi prevedere agilmente non appena rilasciano la nuova tarball di sudo dato che la maggior parte degli aggiornamenti son cambiare versione e hash del tarball e bom. > Io come attaccante, se voglio il root... La maniera in cui stai facendo threat modeling è un po' naive. Per esempio, stai assumendo che l'utente sia sudoer, io no, è una differenza alquanto fondamentale. In breve, hai una via di fare privilege escalation. Comunque il punto è che non c'è un modo per permettere ad un utente di installare robe da cache di terze parti senza rischiare di compromettere il sistema. Poi possiam parlare della praticità dell'attacco, ma resta comunque un flaw del design, che credo sia la ragione per cui han introdotto il local overlay store. | 20:28:33 |
| gecko | * Il fatto che un hash sia "crittografico" non ha nulla a che vedere con la sua predicibilità. L'hash della derivazione lo puoi prevedere agilmente non appena rilasciano la nuova tarball di sudo dato che la maggior parte degli aggiornamenti son cambiare versione e hash del tarball e bom. > Io come attaccante, se voglio il root... La maniera in cui stai facendo threat modeling è un po' naive. Per esempio, stai assumendo che l'utente sia sudoer, io no, è una differenza importante. In breve, hai una via di fare privilege escalation. Comunque il punto è che non c'è un modo per permettere ad un utente di installare robe da cache di terze parti senza rischiare di compromettere il sistema. Poi possiam parlare della praticità dell'attacco, ma resta comunque un flaw del design, che credo sia la ragione per cui han introdotto il local overlay store. | 20:31:04 |
| gecko | * Il fatto che un hash sia "crittografico" non ha nulla a che vedere con la sua predicibilità. L'hash della derivazione lo puoi prevedere agilmente non appena rilasciano la nuova tarball di sudo dato che la maggior parte degli aggiornamenti son cambiare versione e hash del tarball e bom. > Io come attaccante, se voglio il root... La maniera in cui stai facendo threat modeling è un po' naive. Per esempio, stai assumendo che l'utente sia sudoer, nella ipotesi che propongo invece no, è una differenza importante. In breve, hai una via di fare privilege escalation. Comunque il punto è che non c'è un modo per permettere ad un utente di installare robe da cache di terze parti senza rischiare di compromettere il sistema. Poi possiam parlare della praticità dell'attacco, ma resta comunque un flaw del design, che credo sia la ragione per cui han introdotto il local overlay store. | 20:31:24 |
 Marco Turchetto | Per accettare le caches remote devi essere un nix-trusted-user, che non è la stessa cosa di essere sudore ma poco ci manca. E centrare la hash del sudo di chi farà lo switch del sistema è un bel terno al lotto. Devi a tutti gli effetti sapere quale sudo installerà, e lo devi sapere in anticipo. | 22:52:43 |
| Marco Turchetto | Se usi cache di terze parti, rischi SEMPRE di scaricare ciò che non ti aspetti, con o senza questa falla laterale. | 22:55:49 |
| 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 |
| Marco Turchetto | Per me e' ovvio che scaricare binari da fonti non trusted ponga dei rischi. | 10:20:49 |
| Marco Turchetto | Anche su ubuntu se aggiungi una ppa, e ne cambi la priority, puoi pescarti un sudo malevolo. li e' pure piu' semplice perche' basta mettere una versione piu' alta, non devi centrare l'hash giusto. pero' dal dire che e' un security risk e' lunga, no? | 10:23:55 |
| Marco Turchetto | non sono neanche sicuro che tu possa fare il fetch di un binario da una cache secondaria senza aver provato in quella primaria. | 10:29:54 |
| Marco Turchetto | * non sono neanche sicuro che tu possa fare il fetch di un binario da una cache secondaria senza aver provato in quella primaria. anche qui magari c'e' una opzione da abilitare. | 10:30:32 |
| Andrea Ciceri | > Per accettare le caches remote devi essere un nix-trusted-user, che non è la stessa cosa di essere sudore ma poco ci manca. In realta'... https://github.com/NixOS/nix/issues/9649#issuecomment-1868001568 | 10:34:34 |
| Marco Turchetto | Ah ecco, essere un nix-trusted-user è meglio di essere un sudore, nammo bene 🙈 | 10:44:04 |
| Marco Turchetto | * Ah ecco, essere un nix-trusted-user è meglio di essere un sudore, nammo bene 😅 | 10:44:18 |
| gecko | No, non è affatto lunga, è un security risk, infatti son nati altri metodi di distribuzione del software (tipo flatpak e snap). Il punto è che in nix puoi permettere agli utenti di installare quello che vogliono senza compromettere la sicurezza del sistema. Ma questo è vero fintanto che non usi cache non trusted e questa è una limitazione, full stop. Infatti c'è la storia degli overlay. Comunque vedo che continui a spostare il goalpost e glissare sopra le mie osservazioni, mi ritiro da questa discussione poco proficua :P Peace 🕊️ | 13:06:00 |
| Andrea Ciceri | Se ho capito bene lo scenario che dice @gecko sarebbe attuabile tipo cosi': - esiste gia' /nix/store/aaa-sudo-v1 ed e' allegramente usato dagli utenti della macchina- esce sudo v2- un trusted user malevolo (non necessariamente in realta') del sistema usa una cache poisoned cosi e il path /nix/store/bbb-sudo-v2 finisce nello store- altri utenti aggiornano i loro input (o channel o quello che e') cosi' che il risultato della valutazione deilla derivazione di sudo dia sempre il path /nix/store/bbb-sudo-v2, solo che ora questo non viene sostituito usando le cache "buone" perche' gia' presente nello store(stiamo ignorando che un trusted user e' gia' root essenzialmente ma chissene per il ragionamento) Ho capito bene? Comunque pensavo che anche senza coinvolgere gli overlay per lo store (che comunque credo risolverebbero) o [trustix](https://github.com/nix-community/trustix) anche le care vecchie content addressed derivations di cui si parla da anni risolverebbero questo problema: https://github.com/NixOS/rfcs/blob/master/rfcs/0062-content-addressed-paths.md | 16:48:43 |
| gecko | Sì le CAD chiaramente risolverebbero. Il trusted user non deve essere malevolo, solo "ingenuo" e abilitare la cache di un flake (ad esempio) perché gli utenti di quel flake si scocciano a rebuildare da sorgente e lo stressano. | 16:55:58 |
| gecko | * Sì le CAD chiaramente risolverebbero. Solo che è una cosa che non puoi molto deployare in maniera graduale: finché almeno una derivation usata da un altro utente non è una CAD, puoi poisonarlo. Il trusted user non deve essere malevolo, solo "ingenuo" e abilitare la cache di un flake (ad esempio) perché gli utenti di quel flake si scocciano a rebuildare da sorgente e lo stressano. | 16:57:47 |