Tutti gli articoli di Matteo Cappadonna

E’ ufficiale: Microsoft ha rilasciato una distribuzione Linux basata su un Kernel personalizzato

Facebooktwittergoogle_plusredditlinkedin

Con il filone “Microsoft ama Linux” ci siamo abituati a vedere comportamenti sempre più controcorrente rispetto alla storia di Microsoft.

Dal rilascio dei propri software in open source, alla collaborazione con Canonical per il rilascio di uno strato Linux in Windows, fino all’inclusione (e promozione) di distribuzioni Linux officiali nello store Azure, pensavamo di aver fatto il callo a questa nuova tendenza.

Ma proprio in un momento di serenità, ecco l’esplosione: Microsoft rilascia una distribuzione Linux.

Si, potete rileggere la frase, c’è proprio scritto quello!

Un paio di giorni fa, infatti, Microsoft ha annunciato una nuova tecnologia chiamata Azure Sphere e pensata per avere un sistema estremamente sicuro per dispositivi IoT, giocattoli connessi ed altri gadget.

E, dovendo fornire un sistema sicuro, da cosa partire? Da Windows? No, molto meglio avvalersi di un kernel Linux (altamente modificabile) e customizzarlo per le loro necessità.

Ed è quello che è stato fatto, scritto nella pietra o, se vogliamo, nel post ufficiale sul blog di Microsoft:

Azure Sphere will bring to these new chips a new customized operating system built for IoT security. This OS incorporates a custom Linux kernel that has been optimized for an IoT environment and reworked with security innovations pioneered in Windows to create a highly secured software environment.

Azure Sphere porterà a questi nuovi chip un nuovo e personalizzato sistema operativo costruito per la sicurezza dell’IoT. Questo OS incorpora un kernel Linux personalizzato che è stato ottimizzato per gli ambienti IoT e rilavorato con innovazioni di sicurezza già utilizzate in Windows per creare un ambiente software altamente sicuro

Quindi si, c’è Linux, ma l’annuncio sembra non dargli troppo credito, sottolineando che hanno dovuto lavorare sul kernel parecchio per renderlo utilizzabile su dispositivi IoT e, soprattutto, “sicuro come Windows” (…).

Il progetto Azure Sphere è molto più ampio, in realtà, e comprende lo sviluppo di chip ad-hoc, l’OS e servizi cloud a compendio di entrambi, ma il fatto che per la parte centrale di tutto (di fatto, è l’OS che fa parlare l’hardware con il cloud) è stato deciso di non usare un sistema Windows -seppur embedded- è sicuramente una svolta sensibile.

Al momento ne nell’articolo di Microsoft, ne nel loro repository GitHub ufficiale è presente il sorgente di questo kernel, stando alla GPLv2 dovranno rilasciarlo per forza… magari stanno aspettando solo la mail di Garrett.

Cosa ne pensate? E’ l’inizio della fine?

OpenContainerInitiative: finalmente uno standard per la trasmissione di immagini dei container

Facebooktwittergoogle_plusredditlinkedin

Due anni fa parlavamo della nascita della Open Container Initiative sotto il controllo della Linux Foundation. Con l’esplosione dell’uso dei container, e delle tecnologie in grado di gestirli, definire uno standard ufficiale ed aperto per la creazione, l’esecuzione e la trasmissione delle immagini dei container è diventato fondamentale.

E, finalmente, si inizia ad arrivare a qualcosa di completo: già in passato il formato delle immagini ed i runtime sono stati standardizzati dalla OCI, che l’anno scorso ha raggiunto una maturità con il rilascio della versione 1.0; in questi giorni il lancio del progetto Distribution Specification ha definito lo standard anche per il push e pull delle immagini (le operazioni utilizzate per caricare e scaricare le immagini da un registro), andando così a coprire (quasi) tutto il mondo container: come viene creato, come viene eseguito e come viene trasmesso.

Per questa operazione hanno deciso di basarsi sulla definizione del Docker Registry V2; essendo questo un registry dei più utilizzati al mondo (forse il più utilizzato), è sembrato logico prendere le specifiche di come lavorasse e, sulla base di quelle, costruire uno standard che, tendenzialmente, permetterà l’adozione dalla maggior parte dei sistemi di gestione di container senza grosse modifiche.

Ovviamente Docker non può che essere contenta del fatto che la sua implementazione è diventata lo standard, come affermato da Michael Crosby, ingegnere e maintainer in Docker:

Docker’s contribution of the Docker Registry V2 specification aligns with our history of making key open-source projects available to the community. As with the runtime and image specification, Docker’s registry protocol has become a de facto standard with over 40 billion images pulled using this protocol.

Il contributo di Docker alle specifiche del Docker Registry V2 si allinea con la nostra abitudine storica di rendere i progetti open-source chiave disponibili alla community. Insieme al runtime ed alle specifiche delle immagini, il registry protocol di Docker è diventato lo standard de facto con oltre 40 miliardi di immagini scaricate usando questo protocollo.

La notizia in ogni caso è stata accolta molto positivamente da tutti, sia da Amazon con il suo Amazon Elastic Container Registry (che comunque è compatibile con il Docker Registry V2), sia da Microsoft che eroga l’Azure Container Registry (implementato usando proprio il Docker Registry) che Google, fornitore di Google Cloud (di cui non si sa molto riguardo il funzionamento dei registry forniti).

Tutti contenti dunque, abbiamo uno standard completo!
Ora non resta che aspettare che tutti lo abbraccino.

Matthew Garrett di nuovo alla carica: questa volta si punta il dito contro Symantec

Facebooktwittergoogle_plusredditlinkedin

Abbiamo già parlato di Matthew Garrett in passato, dal fork del kernel Linux, fino al recente scambio di opinioni con Torvalds, passando dalla diatriba con Amazon. Insomma, non è certo uno di quei personaggi a cui piace restare in secondo piano.

Recentemente, in un messaggio pubblicato dal suo profilo Twitter, cerca un feedback da parte di Symantec:

Hi @NortonOnline the Norton Core is clearly running Linux and the license requires you to distribute the kernel source code so where can I get it?

Ciao @NortonOnline, il Norton Core chiaramente esegue Linux, e la licenza richiede che distribuiate il codice sorgente del kernel, quindi dove posso prenderlo?

La domanda è molto chiara. Il router Norton Core, un nuovo router WiFi di Symantec ad alta sicurezza, ha a bordo un OS Linux, più nello specifico una distribuzione basata sul progetto QCA Software Development Kit (QSDK), che a sua volta è una piattaforma costruita intorno all’OS OpenWrt, basato su Linux.

Scelta molto indicata per l’uso che ne vuole fare Symantec: invece di un firmware read-only, ha optato per un sistema completo che, permettendo l’aggiornamento del software, gli permette di aggiornare i dispositivi con le ultime patch di sicurezza.

Il problema principale è la licenza stessa con cui questo dispositivo viene venduto:

The product described in this document is distributed under licenses restricting its use, copying, distribution, and decompilation/reverse engineering

Il prodotto descritto in questo documento è distribuito sotto licenze che ne limitano l’uso, la copia. la distribuzione e la decompilazione/reverse enginnering.

Stando a questo, quindi, è in diretto contrasto con quanto previsto dalla GPLv2 sotto cui è licenziato il kernel stesso.

La risposta di Symantec è abbastanza preconfezionata:

Symantec is fully committed to complying with its license obligations in connection with use of open source components in its products. We take these claims seriously and are looking into the matter.

Symantec si impegna pienamente a rispettare i propri obblighi di licenza in relazione all’uso di componenti open source nei propri prodotti. Prendiamo sul serio queste affermazioni e stiamo esaminando la questione

Al momento, dunque, ancora nulla di rilasciato.

Questa non è la prima volta che nascono problemi legali dati dall’uso di software GPLv2 in prodotti embedded, in passato già era capitato alla Monsoon Multimedia nel 2007 che, utilizzando una versione customizzata di BusyBox nei propri hardware, ha alla fine dovuto ammettere di aver violato la GPLv2 e rilasciato il loro codice.

Potremo prima o poi quindi mettere mano al dispositivo super-sicuro di Symantec e capire se questa sicurezza è reale? Staremo a vedere.

Solomon Hykes lascia Docker: il saluto del papà dei container.

Facebooktwittergoogle_plusredditlinkedin

Una settimana fa circa il fulmine a ciel sereno: Solomon Hykes abbandona Docker.

Per chi non lo conoscesse, seppure per l’esattezza non abbia inventato i container, sicuramente è stata la persona che più di tutti ha contribuito a renderli popolari ed uno standard de-facto su cui son nate e sono evolute una serie di altre tecnologie come Kubernetes, per citarne una.

Non si può iniziare a parlare del buon Hykes senza condividere il video di 5 minuti in cui, al PyCon 2013, presentò al mondo Docker, un tool che utilizzavano in dotCloud (società francese fondata da Hykes stesso), per gestire comodamente i container Linux:

Se come dotCloud fornivano servizi per la gestione di applicazioni scalabili usando questa “nuova” tecnologia chiamata container, la presentazione di Docker cambiò il target: finalmente un semplice tool poteva gestire tutto dal network al filesystem, dai namespace dei processi ai cgroup per la gestione delle risorse. Questo fece esplodere il fenomeno al punto che, 5 anni fa, dotCloud cambiò nome come Docker.

Il buon Hykes, che ai tempi era il CEO di dotCloud, insieme alle altre 5 persone al lavoro, decise di assumere un nuovo CEO per Docker in grado di sostenere l’azienda e con esperienza nel ruolo, e si ritagliò il ruolo di CTO (Chief Tecnical Officer). E tutto ha continuato a crescere.

Ora la situazione si è nuovamente evoluta: con la crescita della base clienti di Docker (soprattutto della sua Docker Enterprise Edition), ed in generale della società, si è reso fondamentale trovare un nuovo CTO con l’esperienza necessaria sia al lavoro in team con Steve Singh (attuale CEO), che nella gestione tecnologica della società stessa. E così il ruolo di Hykes cambierà ancora: in un primo momento aiuterà a trovare il CTO ideale al compito e successivamente fornirà la consulenza allo stesso per capire come collaborare al meglio con il team tecnico già presente in azienda.

Sicuramente un ruolo che gli permetterà di mantenere un piede in Docker, lasciandogli però il tempo di continuare a lavorare su altro e chissà, magari, cambiare il mondo dell’IT un’altra volta.

Vi lasciamo al post ufficiale di Hykes sul blog, in cui spiega bene -seppur con un pochino di amarezza- i vari passaggi che l’hanno portato dove è adesso.

BranchScope: ricomincia la giostra delle vulnerabilità per Intel

Facebooktwittergoogle_plusredditlinkedin

Tutto tranquillo sul vostro hardware? Siete finalmente riusciti a completare tutto il patching necessario per Spectre e Meltdown?

Ottimo, adesso è il momento di ricominciare tutto da capo!

E’ di questi giorni la scoperta di una nuova vulnerabilità dei processori Intel, questa volta battezzata con il nome di BranchScope.

Quattro ricercatori di altrettante università, la College of William and Mary, la Carnegie Mellon University, la UC Riverside e la Binghamton University, si sono messi insieme ed hanno pubblicato un articolo (PDF) in cui descrivono questa nuova vulnerabilità che, sfruttando la feature di “branch prediction” dei moderni processori (che utilizza un sistema predittivo per anticipare le possibile operazioni da effettuare al fine di risponderne più velocemente), riesce ad estrarre anche informazioni non proprio legate a questa necessità.

Questo attacco colpisce il “directional branch predictor” un processo diverso da quello interessato da Spectre e riesce ad aggirare alcune protezioni della memoria hardware andando ad operare a livello di sistema; ovviamente le patch applicate per Spectre/Meltdown risultano assolutamente inutili per ovviare a questo tipo di attacco che, seppur simile nel modo di operare, agendo su una “parte” differente dell’hardware lavora indisturbato.

Al momento, come indicato nell’articolo, risultano vulnerabili diversi modelli di CPU Intel, tra le quali quelle delle famiglie Sandy Bridge, Haswell e Skylake.

Alcune mitigation sono già presenti ma quasi sicuramente ci aspetterà un nuovo round di update generalizzato, appena verrà trovato un metodo “standard” di fix e rilasciate le patch per i diversi OS.

Pronti.. apt/yum update… via!

StackOverflow: Linux è più popolare di Windows per gli sviluppatori

Facebooktwittergoogle_plusredditlinkedin

Ogni anno Stack Overflow, il famoso sito di domande e risposte tanto caro agli sviluppatori di ogni angolo del globo, organizza un questionario per capire l’andamento delle preferenze dei suoi utenti in fatto di linguaggi preferiti e di OS, per lo sviluppo e per l’erogazione di tutte quelle applicazioni che, in un modo o nell’altro, hanno contribuito a sviluppare.

Ed è stato pubblicato in questi giorni il risultato del sondaggio di quest’anno che, grazie ai più di 100.000 sviluppatori partecipanti al questionario di 30 minuti (contenente domande che andavano dall’etica nello sviluppo fino alle intelligenze artificiali), si può dire rappresenti un bello spaccato della categoria.

Troviamo delle conferme di risultati degli anni precedenti, da JavaScript come linguaggio di programmazione più usato (sono 6 anni che “vince”) e Node.js come framework, alla prevalenza di database MySQL e SQL Server sopra tutti gli altri; spicca quest’anno però un’altra statistica: Linux ha sorpassato Windows come piattaforma scelta dagli sviluppatori per il loro lavoro, passando dal 32,9% degli intervistati che utilizzavano l’OS OpenSource nel 2016 al 48,3% degli stessi nel 2017.

Linux and Windows Desktop or Server are the most common choices that our respondents say they have done development work for this year. Linux is once again the most loved platform for development, with serverless infrastructure also loved this year.

Linux e Windows Desktop o Server sono le scelte più comuni tra gli intervistati su cui hanno fatto lavoro di sviluppo questo anno. Linux ancora una volta è la piattaforma più amata per lo sviluppo, con l’infrastruttura serverless molto apprezzata quest’anno.

Sicuramente è un ottimo passo per l’OS di Torvalds, e il sorpasso – per la prima volta – nell’uso di Visual Studio Code su Visual Studio come IDE di sviluppo più popolare potrebbe essere complice di questo risultato; Visual Studio Code, infatti, a differenza della sua controparte “old school”, è portabile e gira, tutto sommato, molto bene sui sistemi Linux, facilitando la migrazione di uno sviluppatore da un sistema Microsoft al pinguino, che si ritroverebbe con lo stesso IDE e, magari, un ambiente sottostante più simile a quello in cui la sua applicazione sarà poi erogata. Magari su Azure e magari sempre sotto Linux!

Voi usate tutti Linux per sviluppare, vero?

Microsoft al lavoro per “curare” i problemi delle licenze OpenSource

Facebooktwittergoogle_plusredditlinkedin

Che Microsoft stia investendo parecchio in progetti open source è oramai un dato di fatto, basta leggere le notizie degli ultimi anni.

Dal “Linux is a cancer” di Ballmer acqua ne è passata sotto i ponti, ma le cose si stanno ribaltando più del previsto.

Già, perché pare che Microsoft sia adesso una delle 10 aziende – insieme a Red Hat, Facebook, Google ed IBM, per citarne alcune – che stanno lavorando per estendere il diritto di “sanare” le non conformità delle licenze open source prima di adottare misure legali.

Il problema è dato, a quanto pare, dai termini troppo stringenti della terza versione della licenza GPL, la General Public License creata da Stallman nel lontano 1989 e rinnovata appunto alla v3 oramai da più di 10 anni.

The large ecosystems of projects using the GPLv2 and LGPLv2.x licenses will benefit from adoption of this more balanced approach to termination derived from GPLv3

Il grande ecosistema di progetti che utilizzano licenze GPLv2 e LGPLv2.x potranno beneficiare dall’adozione di questo approccio più bilanciato al posto della loro scomparsa derivata dalla GPLv3

Ma cosa sta succedendo in pratica? Il problema è dato da alcune modifiche introdotte dalla GPLv3 che prevedono la terminazione dei progetti in caso di non-conformità alla licenza degli stessi; e la GPLv3 pare sia molto più stringente in termini di combinazione tra software libero e “meno libero”, al punto che moltissimi progetti – uno fra tutti: lo stesso kernel Linux – non hanno ancora eseguito l’upgrade di versione della licenza poiché renderebbe incompatibile molte delle loro componenti.

Queste 10 aziende hanno deciso di adottare una soluzione più “morbida” rispetto a quella prevista dalla terza versione della licenza, dando la possibilità a chi lavora a questi progetti di avere del tempo per “riadattarsi alle modifiche di licenza richieste”.

Che la GPL sia molto integralista non è una novità, e che questo sia un bene o un male lo definisce solo chi la utilizza, ma il fatto che tutti questi nomi importanti facciano cordata insieme per risolvere questi tipi di problematiche fa pensare che, forse, un problema c’è, ed è di fondo.

Trovati due bug critici in Firefox

Facebooktwittergoogle_plusredditlinkedin

Venerdì scorso Mozilla ha rilasciato un security advisor per avvisare gli utenti di due grossi bug trovati nell’ultima versione di Firefox, il popolare browser.

I due bug sono stati associati a due differenti CVE che, fortunatamente, vengono risolte con l’ultima versione 59.0.1 già disponibile per il download.

Il primo, CVE-2018-5146, affligge libvorbis, la libreria integrata che si occupa dell’encoding/decoding di audio in modalità lossy (ovvero con perdita di qualità). Il bug permette di sfruttare la scrittura in aree di memoria non previste, rendendo possibile l’esecuzione di codice malevolo.

Il secondo è relativo a libtremor, e gli è stata assegnata la CVE-2018-5147. Questa libreria viene utilizzata da Firefox su dispositivi Android e, più in generale, su piattaforme ARM come alternativa a libvorbis. Evidentemente l’alternativa è stata scelta così bene da portarsi dietro gli stessi bug della sua controparte utilizzata sui normali PC.

Quindi, l’aggiornamento è d’obbligo, soprattutto pensando che il banale ascolto di un file audio può portare all’installazione di un rootkit o di un keylogger sui vostri sistemi!