Tutti gli articoli di Matteo Cappadonna

Grande successo per KDE al Google Summer of Code 2018

Facebooktwittergoogle_plusredditlinkedin

Come ogni estate, oramai da anni, anche quest’anno si è tenuto il Google Summer of Code. Questa iniziativa è stata pensata dall’azienda di Mountain View per promuovere l’impegno dei nuovi sviluppatori su software di qualità e -soprattutto- open source.

Dopo essere entrati nel programma (è presente una sorta di selezione, a cui possono partecipare studenti da tutto il mondo), si viene messi in contatto con grandi nomi del panorama open source (da LibreOffice a FreeBSD, da Debian alla Free Software Foundation) che forniscono una serie di progetti tra cui scegliere e che lo studente potrà seguire nello sviluppo nei mesi di pausa estiva dalla scuola.

Tra tutti questi nomi, quest’anno si è notato un particolare interesse per il progetto KDE, che ha visto impegnati addirittura un paio di dozzine di studenti sul famoso desktop environment.
I lavori si sono chiusi qualche giorno fa, ma parecchie cose son state fatte tra cui:

  • La suite dedicata al mondo education GCompris è stata migliorata, ed è ora vicina a raggiungere la release 1.0
  • Miglioramenti effettuati al supporto di LVM e RAID di KDE Partition Manager e l’installer Calamares
  • Aggiunta la possibilità di sviluppare estensioni per il browser Falkon utilizzando JavaScript e QML, in aggiunta al supporto già disponibile per Python e C++
  • Il software di disegno Krita ha ricevuto grandi miglioramenti; il suo gestore dei tile adesso è ottimizzato per il multi-threading, e diverse ottimizzazioni sono state fatte anche nella gestione dei pennelli

Ovviamente i miglioramenti che questi giovani sviluppatori hanno contribuito a portare avanti non si fermano qui, e toccano anche strumenti più “specializzati” come LabPlot e KStars.

Con i soliti metodi tendenti alla trasparenza tipici delle community open source, KDE ha rilasciato uno Status Report ufficiale sui risultati portati dal Google Summer of Code al progetto, con la lista di tutti gli studenti coinvolti. Per la lista completa dell’intera iniziativa, invece, è presente una pagina dedicata sul sito ufficiale.

Noi non possiamo che complimentarci con questi ragazzi e con tutti gli altri, sperando che sia il “battesimo” di tante nuove mani orientate allo sviluppo di software orientati all’open source.

Una versione non ufficiale di LibreOffice finisce nel Windows Store

Facebooktwittergoogle_plusredditlinkedin

Oramai qualsiasi sistema operativo fornisce out-of-the-box una qualche sorta di store, ovvero un software dal quale ricercare, scaricare, installare e tenere aggiornate le applicazioni sul proprio sistema.

Siano essi OS per computer (Linux, Windows, macOS) o per dispositivi mobile (Android, iOS), lo “store” è una di quelle feature che, praticamente, ci si aspetta di trovare e, di base, questa soluzione porta vantaggi sia agli utenti, che dovrebbero essere tranquilli nello scaricare un’applicazione che in qualche modo è stata validata dall’azienda (grossa) che gestisce lo store, sia agli sviluppatori che non devono occuparsi di gestire lato applicazione delle logiche per avvisare l’utente di un aggiornamento disponibile.

Di fatto questo sistema funziona molto bene, ed oramai questi big basano un’ottima parte del loro fatturato sui proventi provenienti da questi store.

Delle volte però, data la mole di contenuti che devono essere gestiti da queste aziende, capita che qualche “sviluppatore” furbo e con pochi scrupoli sfrutti la leggerezza con cui l’utente scarica ed installa questi software da questi store, e che queste applicazioni passino inosservate -almeno per un pò di tempo- nel mare di altre applicazioni pubblicate quotidianamente.

Seppur in questo articolo andiamo a parlare del Windows Store, ovvero quello fornito agli utenti dei sistemi operativi di Microsoft, la vicenda tocca da vicino un software a noi -utenti del pinguino- molto caro: LibreOffice.

Già perchè la suite office libera per antonomasia si è vista pubblicata proprio su questo store, al costo di $2.99 dollari.

Ora, seppure per gli strumenti che offre potrebbe avere senso pagare quella cifra, il problema è che questa versione di LibreOffice è stata pubblicata da uno sviluppatore anonimo, non parte del team dietro al progetto LibreOffice e che, fondamentalmente, sta cercando di fare soldi in maniera illegale su un tool open source.

Italo Vignoli, uno dei co-fondatori di TDF (The Document Foundation, l’organizzazione responsabile di LibreOffice) ha commentato quanto segue:

The Document Foundation has been made aware of an unofficial version of LibreOffice on the Windows Store. We are investigating further, but we want to be clear: this is not an official version created by The Document Foundation, so the app’s page is misleading. The only official source of the software (which can be downloaded for free, i.e., without any cost for the end user) is LibreOffice website. Also, the money from the Windows Store version is not collected by The Document Foundation.

The Document Foundation è stata messa a conoscenza di una versione non ufficiale di LibreOffice sul Windows Store. Stiamo investigando, ma vogliamo essere chiari: questa non è una versione ufficiale creata dalla The Document Foundation, quindi la pagina dell’applicazione è fuorviante. L’unica sorgente ufficiale del software (che può essere scaricata liberamente, senza alcun costo per l’utente finale) è il sito web di LibreOffice. Inoltre, i soldi per la versione del Windows Store non sono ricevuti dalla The Document Foundation.

L’applicazione è ancora presente sullo store (ma non vi forniremo il link), l’ovvio consiglio è quello, nel caso utilizzate sistemi Windows, di non scaricare questa versione ma di fare riferimento al sito ufficiale; seppur, teoricamente Microsoft esegua scansioni di sicurezza su tutti i software prima della pubblicazione sul suo store, non si può essere sicuri al 100% che, oltre a dover pagare un intermediario improvvisato e non ufficiale che non ha contribuito in alcun modo al software, questa versione non contenga anche qualche altra sorpresina (i miner di cryptovalute vanno così di moda in questo periodo).

E se pensate che LibreOffice valga quella cifra, o anche qualcosina in più, loro stessi -come molti software open source- forniscono una pagina per le donazioni, in cui potrete concretamente far sapere agli sviluppatori che apprezzate il loro lavoro e contribuire alla crescita di questo software che, in fin dei conti, molti di noi usano tutti i giorni.

Google aggiorna l’offerta cloud ed aggiunge Kubernetes

Facebooktwittergoogle_plusredditlinkedin

Durante la settimana scorsa Google ha annunciato un rifacimento ed un’estensione della sua piattaforma Cloud Launcer. Per chi non la conoscesse, questo sistema permette di scaricare sia software che interi stack applicativi da eseguire sul loro sistema cloud.

Con il nuovo rebrand prenderà il nome di Google Cloud Platform Marketplace, ed abbreviato in “GCP Marketplate”; l’offerta di Google continuerà ad ampliarsi ed introducendo soluzioni production-ready commerciali basate su Kubernetes, promettendo semplificazioni di deployment, fatturazione e gestione di licenze di terze parti.

Sistemi di questo tipo già li troviamo in altri ambienti, come AWS di Amazon o Azure di Microsoft, ma a quanto pare Google ha deciso di dare un valore in più testando e verificando tutte le applicazioni, non solo per il loro corretto funzionamento, ma anche per quanto riguarda la sicurezza, eseguendo scansioni di vulnerabilità ed accordi con i fornitori per il mantenimento ed il supporto nel tempo.

Glen Kosaka, vice presidente di NeuVector (azienda che fornisce sistemi Kubernetes ed OpenShift con particolare riguardo alla sicurezza) vede questa mossa molto importante per il futuro del mondo cloud ibrido.

Container management of marketplace apps now becomes more simplified, and customers — those responsible for container management — have the confidence that these Google Marketplace apps are tested and compatible with their cloud infrastructure

La gestione dei container delle applicazioni marketplace adesso diventerà più semplificata, ed i clienti — quelli responsabili per la gestione dei container — avranno la sicurezza che queste applicazioni Google Marketplace saranno testate e compatibili con la loro infrastruttura cloud

Fin da subito saranno disponibili centinaia di software in formato “container” su questo marketplace, alcuni dei quali di progetti particolarmente diffusi o “caldi” in questo periodo:

  • WordPress per la gestione dei blog
  • InfluxDB, Elasticsearch e Cassandra per i big data ed i database
  • Apache Spark per le analisi su grossi campioni di dati
  • RabbitMQ per il networking
  • NGinx per la gestione dei webserver

Ce n’è per tutti i gusti quindi; una lista completa la potete trovare a questo link.

E voi? Adesso che Google ha preso in mano anche il discorso sicurezza proverete il loro sistema?

Xen Hypervisor 4.11: la major version che non ti aspetti

Facebooktwittergoogle_plusredditlinkedin

E’ annuncio di questi giorni il rilascio di Xen Project Hypervisor 4.11. Questo progetto open source è oramai sulla piazza da 15 anni, ed è una delle soluzioni più consolidate per la gestione di infrastrutture virtuali.

Così consolidata che viene utilizzata come soluzione da alcuni dei fornitori di servizi cloud più grandi del pianeta: da Amazon (per AWS) ad Oracle, da IBM a Citrix, giusto per citarne alcuni.

Ma, a differenza di quello che si può pensare, questa versione 4.11 non è solo un aggiornamento di minor version, porta con se una totale reingegnerizzazione dei suoi componenti principali.

Il supporto x86, l’emulazione dei dispositivi, la sequenza di boot, tutti questi componenti sono stati riscritti da capo, utilizzando meno codice (che si è tradotto in un minore footprint sul sistema ospite), risultando così più semplice da mantenere e migliorando notevolmente le performance e la scalabilità dello stesso, soprattutto nella gestione delle architetture ARM.

Ulteriori grossi passi avanti sono stati fatti per quanto riguarda la sicurezza; Lars Kurth, uno dei facenti parte al board del progetto, ha dichiarato:

The Xen Project community worked swiftly to address the security needs of Spectre and Meltdown, and continued to match its goals in adding significant features to this release.

La community dello Xen Project ha lavorato alacremente per affrontare le richieste di sicurezza introdotte da Spectre e Meltdown, ed ha continuato a raggiungere i suoi obiettivi aggiungendo tante features a questa release

Inoltre sono state combinate alcune funzionalità di Xen Paravirtualization (PV) e dell’Hardware-Assisted Virtualization (HVM) all’interno di PVH, semplificando le procedure di interfacciamento tra i sistemi operativi supportati e lo Xen Hypervisor, e riducendo in questo modo la superficie di attacchi di tipo VMEscaping (in cui si riesce, dalla Virtual Machine, a passare all’hypervisor che la ospita).

Questo ha quindi generato il nuovo supporto ai “PVH Dom0”; utilizzando Xen in questo modo si riesce a bypassare buona parte di QEMU, rendendo il tutto meno a rischio di bug; gli OS in esecuzione devono però essere patchati per supportare la modalità, ma è stato annunciato che le patch in questione per il kernel Linux e per FreeBSD stanno per essere messe in upstream e, quindi, saranno disponibili già dalle prossime versioni.

Questa versione 4.11 porta quindi tanti miglioramenti, a quanto pare, ed essendo la base -probabilmente- di molti dei sistemi che utilizziamo (anche se non direttamente) non possiamo che essere contenti delle novità. Vi lasciamo all’annuncio ufficiale.

Container Security: tante dashboard esposte su internet

Facebooktwittergoogle_plusredditlinkedin

L’uso dei container è esploso negli ultimi anni, noi stessi abbiamo trattato dell’argomento diverse volte.

Indubbiamente sono comodi: la possibilitá di testare rapidamente software senza preoccuparsi di installare le dipendenze sull’host, come anche la capacità di scalare e/o essere spostati da un sistema (o un OS) all’altro, rendono il deployment rapido e senza pensieri.

Tutta questa rapidità e comodità, però, sta portando molti utenti ad un utilizzo poco responsabile degli stessi; già, perché prima, lavorando direttamente sul proprio sistema, forse si tendeva ad essere più attenti a quello che si andava a fare, ai servizi che si esponevano, alle porte che si aprivano.

La natura di “scatola chiusa” dei container porta, evidentemente, gli utenti meno attenti a pensare di avere tutto sotto controllo, ma è giusto tenere sempre a mente che i container non sono altro che processi in esecuzione sul proprio sistema e come tali vanno trattati.

Proprio in questi giorni uno studio effettuato da Lacework, azienda che si occupa di sicurezza sul cloud, ha portato alla luce che più di 21000 sistemi di orchestrazione ed API di container sono pubblicamente esposte su internet.

Certo, seppur “solo” circa 300 di questi siano accessibili senza autenticazione, lasciando totale libertà agli attaccanti di schedulare e lanciare qualsiasi cosa su quei sistemi, la situazione è tutt’altro che rosea; anche perché ben sappiamo che nessun software è esente da bug, ed una vulnerabilità potrebbe sempre essere scoperta e sfruttata.

Come è immaginabile il 75% di queste dashboard sono esposte da Kubernetes, sicuramente l’orchestrator più utilizzato al momento, seguito da Docker Swarm con un 20% (ricordiamo che Swarm è integrato in Docker stesso).

Si ritaglia un piccolo spazio anche RedHat OpenShift, con un modesto 1%; seppur OpenShift sotto il cofano abbia comunque Kubernetes, l’avere questo sistema esposto porta ad esporre non solo il sistema di esecuzione dei container, ma tutto il processo di creazione, il registry, e tutte le eventuali chiavi di sicurezza caricate nel sistema.

Quindi, se volete utilizzare i container fate pure, sono obbiettivamente molto comodi, ma ricordate bene a cosa andate in contro. A volte basta un nmap per stare più tranquilli.

Gentoo compromesso su GitHub

Facebooktwittergoogle_plusredditlinkedin

Gentoo, fino a qualche anno fa, era una delle distribuzioni più calde nel panorama Linux. La sua natura estremamente didattica data anche dalla community, insieme alla sua malleabilità e possibilità data dal fatto che, fondamentalmente, si compila tutto il software installato con opzioni che ci si può ritagliare sul proprio hardware, ne è un punto di forza che, negli anni, si è andato un pochino a perdere per via dell’uso meno “approfondito” che molti utenti richiedono.

Il funzionamento di Gentoo si basa su Portage, un sistema ispirato ai Port di FreeBSD che tiene conto delle dipendenze e delle informazioni relative ai sorgenti, così da poter compilare ed installare il software correttamente.

Questo Portage si appoggia, come i vari apt o yum, a repository pubblici che però, a differenza dei sistemi basati su binari che contengono anche i pacchetti che vengono installati sul sistema, contengono le istruzioni su dove scaricare i sorgenti e come compilarli ed installarli sul sistema.

Qualche giorno fa, il 28 del mese scorso, pare che uno di questi repository pubblici, e per l’esattezza quello mantenuto su GitHub, i pacchetti siano stati modificati, rendendo non più affidabile quanto presente su quel mirror.

Unknown individuals have gained control of the Github Gentoo organization, and modified the content of repositories as well as pages there. We are still working to determine the exact extent and to regain control of the organization and its repositories. All Gentoo code hosted on GitHub should for the moment be considered compromised.

Individui sconosciuti hanno preso il controllo dell’organizzazione Gentoo su GitHub, e modificato il contenuto del repository così come alcune pagine qui. Stiamo lavorando per determinare l’estensione esatta e riprendere il controllo dell’organizzazione e dei suoi repository. Tutto il codice Gentoo disponibile su GitHub dovrebbe al momento essere considerato compromesso.

Fortunatamente si tratta solo di un mirror, e nel caso utilizziate i repository principali (disponibili su gentoo.org) non avete subito alcun danno. Inoltre, al momento il mirror rimane comunque spento, quindi anche per sbaglio non potrete più utilizzarlo.

La community sta lavorando costantemente per chiudere il discorso al più presto e per assicurarsi che la cosa non accada più, nel frattempo potete seguire le evoluzioni dei lavori sulla pagina dedicata messa a disposizione.

Google diventa Platinum Member della Linux Foundation

Facebooktwittergoogle_plusredditlinkedin

Google, almeno pubblicamente, ha sempre promosso e sostenuto l’ideologia Open Source. Dall’utilizzo di progetti basati su quell’ideale (Linux fra tutti), fino a scrivere e pubblicare loro software che, in alcuni casi, sono stati ampiamente accettati ed integrati in quello che è l’attuale internet; Kubernetes, giusto per fare un esempio tra i più recenti, proviene proprio da Google, cha ha rilasciato il codice di questo tool utilizzato internamente alla comunità, rendendolo di fatto uno dei progetti più “caldi” di questi ultimi anni.

Certo, se andiamo a spulciare bene, Google si tiene ben stretta i propri segreti e, soprattutto quando ci sono in ballo i profitti considerevoli della società, l’open source passa velocemente in secondo piano.

Ma l’ampiezza stessa della società fa si che, se anche qualcosa rimane segreto negli uffici di Menlo Park, i contributi alla community restano così tanti da farle guadagnare il titolo di Platinum Member della Linux Foundation, il livello più alto di membership fornito dalla fondazione (un’altra società ad avere questo livello è, neanche a dirlo, Microsoft).

Con 10000 progetti open source a cui ha contribuito ed il supporto ad alcune delle più ampie community quali Cloud Foundry, Node.js Foundation, Open API Initiative e Cloud Native Computing Foundation (che ha contribuito a fondare grazie proprio a Kubernetes), diciamo che forse un pochino se lo merita questo riconoscimento.

Open source is an essential part of Google’s culture, and we’ve long recognized the potential of open ecosystems to grow quickly, be more resilient and adaptable in the face of change, and create better software. The Linux Foundation is a fixture in the open source community. By working closely with the organization, we can better engage with the community-at-large and continue to build a more inclusive ecosystem where everyone can benefit.

L’open source è una parte essenziale della cultura di Google, e da tanto tempo riconosciamo il potenziale di un ecosistema aperto di crescere rapidamente, essere più resistente ed adattabile al cambiamento, e creare software migliore. La Linux Foundation è un capisaldo nella comunità open source. Lavorando a stretto contatto con l’organizzazione, possiamo interfacciarci meglio con le community nel senso più ampio del termine, e continuare a costruire un ecosistema più inclusivo in cui tutti possano trarre benefici

Questo quanto affermato da Sarah Novotny, responsabile delle strategie open source di Google Cloud, che grazie anche a questo riconoscimento entra a far parte della dirigenza della stessa Linux Foundation.

Che sia un primo passo per un futuro in cui Google effettivamente si sposti completamente sull’open source, o è un ulteriore modo per mostrare una singola sfacettatura -quella più user-friendly- della società?

DockerHub: trovati i primi container contaminati

Facebooktwittergoogle_plusredditlinkedin

Docker è sulla cresta dell’onda da tanto tempo, troppo tempo perchè passasse inosservato.

E, prima o poi, doveva succedere: sono state rilevate le prime immagini di container contaminate, da software di crypto-mining, direttamente sul Docker Hub, il registry ufficiale e pubblico di Docker.

Il registry è un componente fondamentale in un’infrastruttura a container; è il componente da cui Docker (o sistemi che utilizzano Docker come base, ad esempio Kubernetes) scarica delle immagini di container che poi esegue sull’host; una volta fatta la build dell’immagine più o meno specializzata è possibile caricarla su un registry, che può essere privato o pubblico (come nel caso di Docker Hub) così che uno o più altri host possano utilizzare quell’immagine senza doverla rigenerare ex-novo.

Due società che si occupano di sicurezza, Fortinet e Kromtech, in questi giorni hanno pubblicato due articoli in cui rivelano che ben 17 immagini di container Docker avevano al loro interno dei miner di cryptovalute che, all’insaputa degli utenti, utilizzano le risorse delle macchine su cui questi container venivano lanciati per generare una BotNet sufficientemente ampia da trovare qualche cryptovaluta.

Queste immagini, considerate sicure, sono state scaricate ben 5 milioni di volte prima che venissero identificate e rimosse, e sfruttavano installazioni di Docker e Kubernetes configurate male per scaricare ed eseguire uno script di mining, oltre al servizio fornito ufficialmente. Il tutto, cosa ancora più preoccupante, in maniera del tutto automatica.

Of course, we can safely assume that these had not been deployed manually. In fact, the attack seems to be fully automated. Attackers have most probably developed a script to find misconfigured Docker and Kubernetes installations. Docker works as a client/server architecture, meaning the service can be fully managed remotely via the REST API

Ovviamente possiamo assumere con sicurezza che queste non siano state rilasciate manualmente. Di fatto, l’attacco sembra essere totalmente automatizzato. Gli attaccanti hanno probabilmente sviluppato uno script per trovare installazioni Docker e Kubernetes configurate male. Docker funziona in un’architettura client/server, quindi il servizio può essere completamente gestito da remoto tramite API REST

I due articoli mostrano anche gli aspetti tecnici su cui si basano questi attacchi, e spiegano che gli attaccanti sono riusciti a ricavare circa $90,000 in cryptovalute (544.74 Monero per l’esattezza) prima di essere scoperti e che le immagini venissero definitivamente rimosse dall’hub e dai sistemi.

As with public repositories like GitHub, Docker Hub is there for the service of the community. When dealing with open public repositories and open source code, we recommend that you follow a few best practices including: know the content author, scan images before running and use curated official images in Docker Hub and certified content in Docker Store whenever possible

Come per i repository pubblici come GitHub, Docker Hub è li a servizio della comunità. Quando si ha a che fare con repository pubblici aperti e codice open source, raccomandiamo di seguire alcune regole come: conoscere l’autore del contenuto, scansionare le immagini prima di usarle ed utilizzare immagini ufficiali presenti in Docker Hub e contenuti certificati nel Docker Store dove possibile.

Regole di puro buon senso, quindi, noi aggiungiamo che forse partire da immagini base ufficiali, costruirsi le proprie immagini specializzate ed utilizzare un registry privato (lo stesso Docker fornisce una semplice procedura per farlo) è la soluzione più sicura.