1. 4

    Io mi immagino il pirla che aveva configurato male la cache e aveva creato quel problema come si senta ora. Avrà passato un brutto quarto d’ora e adesso invece mezza politica italiana e il COPASIR stanno lavorando per parargli il culo.

    1. 2

      Io non ci posso credere, già allora era evidente che “l’attacco hacker” fosse una cazzata. Davvero stanno cercando di coprire tutto? C’è qualche organo rilevante che possa intervenire?

      1. 1

        Da quanto ne so, le penali dovute ad inottemperanze in materia di GDPR sono salatissime (tanto da mettere a rischio i bilanci anche di aziende medio/grandi). Magari vogliono solo evitare il disastro economico.

        Chissà quanti “accrocchi” ci sono dietro… non oso immaginare :D

        1. 1

          Se ti bucano, sei inottemperante.

          A meno che non usino uno zero day. Ed anche lì, dopo averlo dimostrato, bisogna anche giustificare la scelta di quello specifico software.

    1. 1

      ma da quello che scrivono pare non sia previsto un compenso economico per il loro lavoro… c’è qualcosa che mi sfugge? Non mi sembra normale

      1. 1

        lo sviluppo di Immuni non è pagato dallo stato, è offerto pro-bono

      1. 3

        Io purtroppo sono in piena sessione, quindi principalmente studio (meccanica dei robot e sistemi real-time). Quando riesco a scrivere un po’ di codice mi diverto a leggere questo libro chiamato Essentials of Compilation che accompagna nella scrittura di un compilatore per x86 in racket (link: http://jeapostrophe.github.io/courses/2019/spring/406/notes/book.pdf)

        1. 3

          Davvero si bullano delle “nostre incredibili doti investigative” ?

          1. 3

            vabe’, non stiamo a guardare il dito, questo fatto è una porcheria

            1. 1

              A me sembra ironico

            1. 5

              Il kernel Linux contiene già diverse centinaia di system calls e ora, dopo lunghissimo dibattito, si arriva ad aggiungere quest’altra che serve solo a risparmiare tre chiamate in fila (open, read, close).

              Purtroppo c’è da applaudire perché è uno use-case frequentissimo, sia per leggere dalla gerarchia sysfs (i parametri del kernel esposti sotto forma di files, come da tradizione del Plan9: proc, sys…), sia per leggere files fino a 4k (file di configurazione, ecc.). Nel primo caso basterà qualche breve strncmp per rintracciare i dati da leggere, senza neppure avviare tutto l’ambaradan di recupero inode/block da un filesystem.

              Ho detto “purtroppo” perché la semplicità dell’interfaccia “tutto da files” va bene quando i carichi di lavoro non sono grossi (così come l’invenzione dei cgroups per blindare meglio il sistema, perché il modello utenza/gruppo/permessi non bastava più). Non siamo più ai tempi dei primi Unix con poche decine di syscalls. (Magari sarebbe ora di ripensare il design di sistemi operativi senza partire dalle oltre tremila pagine dello standard Posix)

              Questa READFILE mi ricorda parecchio i dischi di nuova concezione (letti e scritti con key/value anziché con numero settore/cilindro/traccia), tecnologia commercialmente in giro già da diversi anni.

              1. 1

                Capisco la tua prospettiva: in effetti è un caso d’uso frequente.

                Tuttavia l’uniformità di interfaccia di un sistema minimale come Plan 9, le cui chiamate di sistema sono abbastanza ortogonali, ha vantaggi di scala che le alternative mainstream (Chrome su Linux, Chrome su Windows, Edge su Windows, Firefox su…) si sognano.

                Si tratta però di una asimmetria interessante: l’ottimo locale (l’efficienza di fare una singola syscall invece di tre) diventa irrilevante globalmente. Ma poiché tutti pensano ancora ai sistemi operativi “un computer alla volta”, si ignorano i costi globali dovuti al’incremento di complessità (la nuova syscall genererà casi su autoconf in migliaia di tool) e si festeggia i pochi millisecondi guadagnati.

                Per contro, devo dire, l’asimmetria è così netta da farmi riflettere sull’architettura di Jehanne che invece ottimizza tutto globalmente, sacrificando l’efficienza locale.

                Chissà se esiste un’architettura semplice capace di salvare capra e cavoli?

                1. 2

                  Molto interessante Jehanne, grazie di averlo nominato.

              1. 2

                Molto interessante, fa capire tanti limiti di Vim.

                pensato per essere usato in un ambiente POSIX in concerto con altri tool (nella mia esperienza questo è sia un pro che un contro, ma limitarsi a questo tipo di minimalismo mi ha dato un’ottica diversa anche sulla programmazione in generale)

                Vuoi approfondire questo concetto? Io sarei curioso…

                1. 5

                  Certo. Se hai usato vim ti sarà probabilmente familiare il linguaggio di scripting di vim. Emacs ne ha uno analogo (Emacs lisp). Di fatto sono linguaggi sufficientemente complessi (per quanto il linguaggio di vim sia decisamente bizzarro) e si tende a scrivere plugin con funzionalità molto complesse esclusivamente con quelli. Kakoune ha un linguaggio di scripting (che è lo stesso dei comandi, esattamente come per vim), ma è molto più limitato. L’estensione funziona attraverso interazione con comandi esterni o in altri modi molto in stile UNIX (motivo per cui, su Windows, era necessario usare cygwin oppure ora WSL: kakoune ha bisogno di un ambiente POSIX sotto). Faccio un esempio: il parsing dei file .editorconfig, che scrissi tempo fa e ora fa parte degli script forniti di base. Scrivere il parsing del file con il linguaggio di kakoune è pressoché impossibile. Allora come si implementa? Si usa il programma esterno “editorconfig”, che raggruppa tutti i vari .editorconfig presenti nel path e scrive in stdout le regole di indentazione e così via. Queste vengono parsate da un altro programma esterno, in questo caso “awk” che è presente su tutti i sistemi POSIX. Si sarebbe potuto usare un qualsiasi altro programma esterno per il parsing, ma spesso nel core si trovano usati programmi standard di POSIX. La parte awk si occupa di tradurre le regole di indentazione di editorconfig nei corrispondenti comandi di kakoune, e kakoune legge l’output di awk e lo esegue al volo.

                  Si cerca quindi di seguire la filosofia unix “ogni programma fa una cosa e la fa bene”. Per dirne un’altra, kakoune stesso come editor è molto ridotto, non ha split window ad esempio, bisogna usare tmux oppure un tiling window manager.

                  Gli svantaggi che ho trovato: scrivere gli script kakoune diventa di solito una questione di scrittura di “colla”, difficile da leggere e poco debuggabile. Spesso chi usa BSD o mac trova che questi script non funzionano nonostante usino solamente comandi esterni POSIX, perché ad esempio GNU grep aggiunge flag al grep definito da posix che non vanno lì. Meccanismi più complicati di interazione con l’esterno ,tipo file creati con mkfifo, che permettono la lettura asincrona di risultati di comandi, sono notevolmente complicati (però ad esempio è così che si ha l’integrazione con “make”).

                  Banalmente nemmeno “if/else” è presente nel linguaggio di kakoune, devo chiamare esternamente sh solo per questo. Quindi la programmazione a mio avviso è un po’ scomoda, però fa riflettere molto su quante cose si riescano ad ottenere senza introdurre troppe feature nel programma e concentrandosi su dei meccanismi di base di interazione.

                  Scusa per il papiro, in realtà mi sono reso conto che avrei ancora molto da dire ma per ora basta così. Lo script per editorconfig a cui mi riferivo sopra è questo: https://github.com/mawww/kakoune/blob/master/rc/detection/editorconfig.kak

                  1. 4

                    Ricorda molto ACME, come filosofia.

                    1. 2

                      Decisamente sì (del resto plan9 è più unix degli unix), però kakoune è molto più ispirato a vim come interfaccia (modalità, comandi oggetto/verbo, interazione da tastiera). Tuttavia c’è stato qualche esperimento che potrebbe interessarti: https://github.com/mawww/kakoune/pull/3116, https://github.com/eraserhd/kak-plumb

                    2. 1

                      No, tranquillo, è un commento molto interessante sui limiti di questa impostazione minimalista e modulare (o dovrei chiamarla filosofia UNIX?). Impostazione che tral’altro ho l’impressione sempre più attaccata: vedi la nuova home o systemd.

                  1. 1

                    Per ora è solo il frontend, prepariamoci ad una settimana di espertoni sulla review di source code tra giornali, tv etc…

                    1. 1

                      Ma ci si aspetta che rilascino il backend?

                      1. 1

                        Non ne ho idea, però della UI onestamente frega poco, personalmente.

                        1. 1

                          Concordo - o meglio, avere il codice dell’app dà una sicurezza in più sul fatto che non facciano cose strane. Personalmente lo vedo un po’ difficile che rilascino il backend, ma non sono informato sulle loro intenzioni.

                          1. 2

                            credo che non ci sia un vero e proprio backend, se c’è fa solo da middleware per andare sulle API Apple/Google di contact tracing. Ho fatto parte del famoso team NoiApp per un po’ di tempo ed il backend faceva poco o nulla.

                            1. 1

                              Si in effetti usando l’architettura Apple/Google per il tracking non serve a molto. Sarebbe servito se il modello fosse in-house, stile UK per dire.

                    1. 4

                      Al di là delle controversie sull’applicazione in sé, spero che questo diffonda un po’ il concetto di open source anche a chi non è dentro il campo tecnologico. Sarebbe bello se le applicazioni/siti front-facing del servizio pubblico fossero open source.

                      1. 3

                        Sarebbe bello se le applicazioni/siti front-facing del servizio pubblico fossero

                        Per legge ormai tutto il software sviluppato per la PA deve essere rilasciato open source.

                      1. 2

                        Sarei felice se fosse stato manomesso volutamente, ma guardando di sfuggita i report del leak di dati non sembra molto un attacco, piuttosto un sistema talmente buggato da permetterlo. Pensandoci magari potrebbe essere una race condition nel manager di sessione vista solo ora per via dei troppi utenti?

                        1. 1

                          A me puzza di unsigned integer overflow in una chiave primaria.

                          1. 2

                            O un hash di sessione troppo debole con alta probabilità di conflitti