 | Nix Milan | 118 Members |
| https://milano.nix.pizza/ | 9 Servers |
| Nix Milan | 118 Members |
| https://milano.nix.pizza/ | 9 Servers |
| Sender | Message | Time |
|---|---|---|
| 1 Mar 2026 | ||
 Andrea Ciceri | Non abbiamo piu' meetup, so che avevamo discusso gia' di passare ad alternative ma siccome non abbiamo deciso nulla per questa volta ho deciso io in maniera non democratica di provare mobilizon. Fate sapere se avete problemi o manca qualche informazione fondamentale. | 13:58:24 |
| Andrea Ciceri | PROSSIMO MEETUP SABATO 14 MARZO https://mobilizon.it/events/096bf456-efd6-4230-9ddc-0cce7c72046a | 13:59:09 |
| Andrea Ciceri | * Non abbiamo piu' meetup, so che avevamo discusso gia' di passare ad alternative ma siccome non abbiamo deciso nulla per questa volta ho deciso io in maniera non democratica di provare mobilizon (altrimenti non ne uscivamo piu'). Fate sapere se avete problemi o manca qualche informazione fondamentale. | 14:00:07 |
| Andrea Ciceri | Quanto vi iscrivete vi da una ricevuta? Perche' io vedo solo "Anonymous participant" (immagino che chi si sia iscritto lo abbia fatto tramite e-mail, sena iscriversi al sito) | 14:12:45 |
 Francesco |  Download image.jpeg | 14:18:16 |
| Francesco | Sarò stato io | 14:18:29 |
 Nonno Felice |  Download image.jpeg | 14:18:31 |
 Tonio Gela | Same mail | 14:19:13 |
| Andrea Ciceri | Non ha molto senso cosi' pero', nella remota ipotesi che arrivino piu' persone di quelle iscritte come capiamo chi e' davvero iscritto? | 14:20:16 |
| Nonno Felice | Non riesco a vedere la lista delle email? | 14:24:39 |
| Nonno Felice | * Non riesci a vedere la lista delle email? | 14:24:42 |
| 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 |