Tutti gli articoli di Matteo Cappadonna

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.

Puppet si compra Reflect: nuovi report in arrivo?

Facebooktwittergoogle_plusredditlinkedin

Puppet credo che oramai sia un nome ben conosciuto nel mondo dell’IT. Partito come un progetto per scrivere del codice che sarebbe servito per rilasciare rapidamente nuovi sistemi, si è presto evoluto in un’azienda a se stante, creata nel 2005 ed ancora attiva e vigorosa.

Vi abbiamo già parlato di Puppet in passato e, nonostante il software sia open source, liberamente scaricabile ed installabile, l’azienda Puppet ha prima iniziato a fornirne una versione Enterprise (comprensiva di una console di gestione centralizzata non solo per la gestione delle esecuzioni, ma anche per la definizione di nuovi workflow), per poi arrivare a proporre software “di contorno” per migliorare l’uso di Puppet stesso, tra cui Discovery (un sistema di inventory) e Pipelines (per gestire flussi di Continuous Integration/Continuous Delivery).

In questi giorni l’azienda ha annunciato di aver acquistato Reflect, una startup abbastanza giovane (nata tre anni fa) che si occupa di sistemi di visualizzazione di dati.

Lo fa però in maniera leggermente diversa della concorrenza: se le aziende che si occupano di questa cosa normalmente forniscono prodotti per gli utenti finali, Reflect ha creato una sorta di sistema data-visualization-as-a-service, fornendo agli sviluppatori sistemi semplici per aggiungere capacità di analytics nei propri software, cosa che permetterebbe di aggiungere informazioni ai report di Puppet in maniera quasi istantanea.

We generate so much data, and we’ve got different visualization and reporting capabilities… but it’s never enough. Customers are looking for richer tools with more interactive capabilities, extensibility and the ability to customize the way data is presented based on roles. With Reflect’s capabilities integrated across all Puppet products the possibilities are endless.

Noi generiamo tantissimi dati, ed abbiamo diversi metodi di visualizzazione e reportistica… ma non è mai abbastanza. I clienti cercano soluzioni più ricche con capacità più interattive, estensibilità e l’abilità di personalizzare i metodi in cui vengono presentati questi dati basandosi suoi ruoli. Con le funzionalità di Reflect integrate in tutti i prodotti Puppet le possibilità sono infinite

Da quanto afferma Sanjay Mirchandani, attuale CEO di Puppet, parrebbe che questa acquisizione porterà Puppet a fare quel salto in avanti che, forse, potrebbe portarlo in testa alla concorrenza.

La battaglia è ancora aperta?

Le applicazioni Linux sbarcano sul Chromebook Plus di Samsung

Facebooktwittergoogle_plusredditlinkedin

Recentemente vi abbiamo parlato della possibilità valutata da Google di permettere l’uso di applicazioni native Linux sui suoi Chromebook, e sembra che il discorso sia piaciuto al punto che non solo sta diventando una realtà, ma anche altri produttori di Chromebook stanno iniziando ad implementare questa feature.

Per iniziare ricapitoliamo un attimo: i Chromebook sono dei laptop “a basso costo” (in realtà ci sono versioni che raggiungono prezzi quasi in linea con i laptop classici) pensati per l’esecuzione di ChromeOS, un OS sviluppato da Google, basato su Linux, con il browser Chrome come interfaccia principale. Fondamentalmente, tutto online, nulla in locale, servizi Google come cuore centrale di tutto.

Quanto questo sia cosa buona è giusta è opinione del singolo, ma la varietà (e “gratuità”) dei servizi forniti dalla società californiana, unita al costo ridotto dell’hardware ed all’ampia disponibilità di connessioni WiFi pubbliche sul territorio, ha fatto si che queste soluzioni prendessero molto piede, soprattutto nell’ambiente scolastico e sul territorio americano.

Da qui a voler che i dispositivi facessero qualcosa in più il passo è stato breve; da metodi più o meno esoterici per installare Linux puro, alla recente presa di coscienza da parte di Google che, forse, sbloccare alcune funzionalità dell’OS sottostante per permettere un uso più vario del dispositivo poteva portare a nuovi utenti, oramai sembrava che applicazioni Linux (o l’intero OS) su Chromebook stessero diventando sempre più una realtà.

Dopo alcuni leak e qualche mezza presentazione, un mesetto fa le applicazioni Linux su ChromeOS sono state ufficializzate da Google, seppur ancora in versione “beta”, ma al momento disponibili solo sul Pixelbook, il portatile più costoso della gamma Chromebook (stiamo parlando di un prezzo di partenza di $1000).

Questa possibilità, però, pare piaccia molto, ed anche altre aziende si stanno avvicinando a fornire qualcosa di similare; è notizia di questi giorni che il progetto Crostini è diventato disponibile (sempre in modalità beta) anche sul Chromebook Plus di Samsung.

Questo dispositivo ha una fascia di prezzo ben diversa, attestandosi a meno di $500 per la versione Plus e poco più di $500 per quella Pro, e potrebbe sdoganare le applicazioni Linux su un target più ampio di utenza ChromeOS.

La notizia è stata data su Reddit, dove l’utente bdovpro ha segnalato la cosa, spiegando anche come attivare la feature.

Già in passato abbiamo visto tentativi di portare Linux ad un utenza più “generica” (ricordate gli EeePC di Asus?) ed effettivamente l’aver accesso ad applicazioni più articolate di quelle online su dispositivi a basso costo, potrebbe far abituare i giovani studenti utenti di Chromebook a software quali Gimp, Firefox o LibreOffice, stendendo le basi per un futuro utente Linux.

Che la visione sia troppo rosea? Chi lo sa, magari anche in questo caso (come già avvenuto per gli EeePC) sarà tutto una meteora.

Tesla inizia finalmente a rilasciare il codice opensource delle sue auto

Facebooktwittergoogle_plusredditlinkedin

Non è segreto che sotto il cofano delle automobili Tesla, così come in quello di parecchi altri produttori, si celi il nostro amico pinguino, incaricato di parecchie cose, dalla mera gestione dell’infotainment, fino ai display digitali ed HUD.

E l’azienda automobilistica di Elon Musk è già stata redarguita in passato per via del fatto che non rilasciava i sorgenti; nel 2013 la SFC (Software Freedom Conservancy) aveva contattato Tesla per avvisare di una grave violazione: i clienti che acquistavano la famosa Model S, il cui sistema conteneva un kernel Linux e BusyBox, non solo non riceveva il codice sorgente, ma neanche gli veniva offerta la possibilità di richiederlo.

Da allora Tesla sta lavorando (seppur lentamente) insieme alla SFC per pubblicare il codice sorgente senza violazioni di licenze e, contemporaneamente, mantenendo il controllo su alcune sue tecnologie esclusive, ed il lavoro di questi anni ha portato in questi giorni al rilascio di parte del codice sorgente della Model S e della Model X sul repository Tesla su GitHub.

Work is underway on preparing sources in other areas as well, together with a more coordinated information page. We wanted to let you know about this material as it is available now while work continues on the other parts.

Stiamo lavorando nel preparare i sorgenti anche nelle altre aree, insieme ad una pagina informativa più coordinata. Volevamo mettervi al corrento di questo materiale ora che è disponibile mentre continuiamo a lavorare sulle altre parti

Con questa dichiarazione Tesla, pur non permettendo ancora di compilare i binari da utilizzare sulla nostra Tesla fatta in casa, indica la volontà di impegnarsi nel rilascio del codice sorgente.

Dall’altra parte l’opinione di Kuhn e Sandler della SFC è più realista:

We often wish we could celebrate the triumph of moving from a no-source-or-offer violation to the next step of ‘incomplete sources provided’. However, we also can’t lose sight of the fact that compliance means meeting all GPL’s requirements, so we don’t convey false hopes with an incomplete release. We must ultimately remain focused on user freedom in our efforts.

Spesso speriamo di poter celebrare il trionfo del passare da una violazione di tipo “nessun-sorgente-o-offerta” al passaggio successivo di “i sorgenti incompleti sono ora disponibili”. Comunque, non possiamo perdere di vista il fatto che l’essere conformi significa rispettare tutti i requisiti della GPL, quindi non nutriamo false speranze con una release incompleta. Alla fine dobbiamo restare concentrati nel nostro impegno sulla libertà degli utenti.

Quindi il passo è sicuramente valido, ma l’intenzione pare sia quella di non smorzare la presa sulla società del buon Musk, ma di continuare a verificare, ed aiutare, nella conformità a quello che la GPL, usando Linux nel proprio cuore, li impegna a fare.

Noi seguiremo la faccenda

GNOME Foundation fa jackpot!

Facebooktwittergoogle_plusredditlinkedin

Nonostante il largo uso dell’ambiente desktop GNOME su almeno due delle distribuzioni Linux più importanti, Fedora e Ubuntu, GNOME non è mai stato un progetto particolarmente redditizio.

Se andiamo a vedere gli introiti netti (dati dalla differenza tra il ricevuto e lo speso) di fatto negli ultimi anni gli introiti della GNOME Foundation, l’organizzazione no-profit alla base del progetto GNOME, sono andati via via assottigliandosi sempre di più:

  • 2014: $174.484
  • 2015: $151.019
  • 2016: $77.373

Certo, il progetto tendenzialmente dovrebbe poter proseguire anche senza introiti, ma oramai è di un’estensione tale che del carburante è necessario.

E’ notizia di questi giorni, fornita dalla stessa GNOME Foundation, un donatore anonimo ha assicurato donazioni per 1 milione di dollari, che saranno emesse nei prossimi due anni.

An anonymous donor has pledged to donate up to $1,000,000 over the next two years, some of which will be matching funds. The GNOME Foundation is grateful for this donation and plans on using these funds to increase staff to streamline operations and to grow its support of the GNOME Project and the surrounding ecosystem. While the GNOME Foundation has maintained its position as a proponent of the GNOME Project, growth has been limited. With these funds, the GNOME Foundation will be able to expand and lead in the free software space.

Un donatore anonimo si è impegnato a donare fino ad $1,000,000 durante i prossimi due anni, alcuni dei quali assicureranno i fondi. La GNOME Foundation è riconoscente per questa donazione ed ha pianificato di usare questi fondi per incrementare il personale per le operazioni di gestione di aumentare il supporto al Progetto GNOME ed all’ecosistema che ci sta intorno. Mentre la GNOME Foundation ha mantenuto la sua posizione di sostenitrice del Progetto GNOME, la crescita è stata limitata. Con questi fondi la GNOME Foundation potrà espandersi ed affermarsi nel free software.

Grande entusiamo, come è ovvio che sia, della fondazione, anche se molti utenti si chiedono chi sia questo/a donatore/donatrice. Un privato? Diversi sono convinti che dietro ci sia una qualche azienda grossa, come Red Hat o Canonical che, sfruttando il progetto, ne vuole assicurare la sopravvivenza per non dover investire nello switch a qualcos’altro o nell’effort di doverlo prendere in gestione in toto.

E’ opinione di altri utenti che il non saperlo sia un bene, sia per il fatto che il beneficiario (quindi la Foundation) non deve decidere se accettare o rifiutare la donazione a seconda della sorgente della stessa, sia perchè in questo modo non si associa in alcun modo la GNOME Foundation con l’associazione/donatore che l’ha effettuata.

Voi come la vedete? Pensate che il futuro possa essere più roseo per il desktop del piedone?

Systemd ripensa i chroot introducendo i Portable Services

Facebooktwittergoogle_plusredditlinkedin

Quando si parla di systemd, il sistema di init ideato da Lennart Poettering e diventato oramai il default per le principali distribuzioni Linux, ci si avventura sempre in un campo minato.

Tra i sostenitori ed i detrattori, il rumore è molto alto, ed ognuno mette sul piatto i vantaggi e gli svantaggi di usare un sistema piuttosto che un altro.

Obiettivamente, però, è risaputo che systemd tende a voler fare da padrone il più possibile: nato per la gestione del mero avvio/stop dei servizi, si è avventurato nella gestione dei componenti network, di mount dei filesystem, e di cose che, in effetti, potrebbero non essere necessarie all’interno di un sistema di init, ma che vengono incluse al grido di “semplificazione della gestione”.

Con la prossima versione del sistema, la 239, sarà inclusa una feature sulla quale lo stesso Poettering sta lavorando da mesi: i Portable Services.

Ma di cosa si tratta? Guardando la documentazione presente sul repository Git del progetto, pare sia una feature atta a semplificare l’uso sul proprio sistema di servizi imprigionati all’interno di chroot, ovvero servizi che vedono una porzione del filesystem convinti di vederlo tutto (ok, stiamo semplificando).

Fondamentalmente quello che si vuole raggiungere è:

      Il raggruppamento delle applicazioni in oggetti riutilizzabili, ovvero la possibilità di raggruppare più di un servizio, i relativi binari, e tutte le dipendenze in “immagini”, ed eseguire questi servizi direttamente da li
      Il rafforzamento della sicurezza tramite il sand-boxing, ovvero la chiusura di questi servizi in aree ben specifiche, senza possibilità di uscire e “vedere” il resto del sistema

Ma dove abbiamo già sentito questi concetti, seppur in maniera leggermente differente? Ah, già, i tanto chiaccherati container!

E questo lo sa bene chi ha aggiunto questa feature, al punto da fare una chiara distinzione:

The “portable service” concept ultimately will not provide a fully isolated environment to the payload, like containers mostly intend to. Instead they are from the beginning more alike regular system services, can be controlled with the same tools, are exposed the same way in all infrastructure and so on. Their main difference is that the use a different root directory than the rest of the system.

Il concetto di “portable service” alla fine non fornisce un ambiente totalmente isolato, come intendono fare i container. Invece sono fin dall’inizio più simili ai servizi di sistema, che possono esse controllati con gli stessi tool, e che sono esposti alla stessa infrastruttura, e via dicendo. La loro differenza principale è che usano una root directory differente dal resto del sistema.

E da qui, ecco il paragone con le prigioni chroot. Di base, quindi, un “Portable Service” è un’alberatura di directory di un OS all’interno di una particolare directory, o inserita in un’immagine disco (se preferite questa solizione), e che può essere agganciata o sganciata dal sistema.

Quando viene agganciata, le units systemd (i servizi, etc.) presenti all’interno di quell’alberatura vengono rese disponibili nel sistema principale, e possono essere gestite esattamente come units locali, nonostante siano eseguite all’interno della sola alberatura di riferimento; ovviamente, nel momento in cui viene sganciata questa alberatura, tutte queste nuove units spariscono dal sistema.

Insomma, a quanto pare sembrerebbe niente di più che un sistema estremamente comodo (se siete legati all’uso di systemd) per gestire ambienti chroot in maniera trasparente, come fossero normali servizi del sistema, il che sembra interessante.

Uno dei punti di forza sottolineati è che non è presente una procedura unica per la generazione di queste alberature, ma è possibile utilizzare il tool che si preferisce, da dnf a debootstrap, da pacstrap a zypper.

E nell’ottica di fornire un sistema centralizzato per tutto, cosa che entusiasma Poettering, vengono forniti anche due nuovi tool:

  • mkosi: un wrapper intorno ai tool citati sopra per la generazione di alberature di OS
  • portablectl: che affiancherà systemctl nella gestione di questi specifici servizi

Voi come la vedete questa introduzione? Sarà una buona cosa che in questo periodo di spinta sui container si usi ancora del tempo per (ri)affermare alternative come gli ambienti chroot o è inutile allo stato attuale?

Facebook rilascia il bilanciatore Katran in OpenSource

Facebooktwittergoogle_plusredditlinkedin

Facebook non è nuova, come anche altri big di Internet, a rilasciare applicazioni che ha sviluppato per necessità interne in open source.

Che sia software, o hardware, Facebook sembra sempre molto aperta a rilasciare codice, e ne è dimostrazione il rilascio in questi giorni di Katran, un bilanciatore network da lei sviluppato.

In pratica, come lungamente raccontato nell’articolo di presentazione pubblicato da Facebook stesso, Katran è un bilanciatore layer 4 (nella pila ISO/OSI), ovvero si occupa del trasporto operando sui singoli pacchetti (tipicamente TCP), invece che a livello applicativo (layer 7, come HTTP).

In parole povere, Facebook ha distribuito in tutto il mondo dei Point of Presence (PoP), ovvero dei proxy che accettano le richieste pubblicando VIP (Virtual IP) differenti per locazioni geografiche, e che distribuiscono il traffico sui server di backend: sono solo questi che si occupano, realmente, di gestire le richieste e rispondere ai client.

E fino a qui, nulla di nuovo sotto il sole; ed allora per quale motivo Facebook si è sviluppato un proprio sistema invece di utilizzare uno degli innumerevoli disponibili (sia open source che non)? Beh, probabilmente proprio perché è Facebook, ed il traffico che si trova a gestire è decisamente superiore rispetto a quello di molti altri player del settore.

Inoltre Katran è un Software Defined Load Balancer -ovvero un’architettura distribuita di load balancer definita però a livello di codice in un punto centralizzato- il che sicuramente ha parecchi vantaggi in architetture così estese e, tendenzialmente, così automatizzate come quelle di Facebook; infine, l’azienda aveva dei requisiti ben specifici a riguardo:

  • Doveva girare su server Linux accessori, magari già utilizzati per altro, non essere legato ad hardware particolari
  • Poter coesistere con altri servizi sullo stesso server
  • Permettere il disservizio (in caso di aggiornamento o manutenzione) minimizzando l’impatto o l’effort necessario alla gestione, il tutto per evolvere rapidamente nel tempo.
  • Essere facilmente monitorato e debuggato con strumenti semplici e sempre disponibili, quali tcpdump

Il funzionamento di questo bilanciatore, seppure spiegato nel dettaglio nell’articolo, è abbastanza classico, ma il dover gestire una mole considerevole di traffico ha portato Facebook ad applicare alcuni accorgimenti per ottimizzarne il funzionamento, nonché l’utilizzo di feature recenti del kernel Linux. Ecco alcuni esempi:

  • l’applicazione di metodologie di gestione degli hash, che permettono di non dover sincronizzare lo stato delle connessioni tra le varie istanze del bilanciatore
  • la gestione del traffico in modalità DSR (Direct Server Return), in modo da non passare dal bilanciatore anche per la risposta ed evitare quindi che diventi un collo di bottiglia
  • con una combinazione di XDP (eXpress Data Path) ed eBPF (extended Berkeley Packet Filter) per accedere e gestire il pacchetto network appena entrato nella scheda di rete e prima che il kernel lo intercetti.

Insomma, tante tecnologie e tante idee: se anche non dovessimo utilizzare questa soluzione, alcune note possono stuzzicare la fantasia per migliorare quanto già gestiamo.

Potete comunque scaricate il sorgente del balancer direttamente dalla pagina GitHub del progetto. Buona lettura!

Il protocollo Git raggiunge la versione 2

Facebooktwittergoogle_plusredditlinkedin

Che vogliate o no, il sistema di versionamento Git è oramai diventato uno standard per la revisione del codice.

Questo sistema è stato creato nel “lontano” 2005 da Linus Torvalds come sostituto del metodo di versionamento proprietario che veniva utilizzato precedentemente dal kernel Linux. E, la sua larga adozione, lo ha reso famoso per essere il software scritto da Torvalds più diffuso in assoluto (ben più dello stesso kernel). Da allora molti passi sono stati fatti, ed ormai il progetto è nelle mani della comunità.

Proprio in questi giorni Brandon Williams, membro del team Git-core, ha pubblicato sulle blog relativo all’open source di Google l’introduzione alla versione 2 del protocollo Git.

Per l’esattezza le novità impattano il wire protocol di Git, ovvero le metodologie che il protocollo utilizza per clonare, aggiornare e pubblicare le modifiche tra il client ed il server; questa novità, come indicato dall’articolo, risolve una delle parti più inefficienti dell’intero protocollo, oltre a gettare e basi per miglioramenti futuri.

In breve, allo stato attuale (prima di questa versione), ogni volta che un client dava un comando di fetch al server (per avviare lo scaricamento di modifiche pubblicate sul ramo -o branch- sul quale si sta lavorando), questo rispondeva con una lista completa di tutte le referenze sul server, anche nel caso il client stia richiedendo lo scaricamento delle modifiche su un singolo ramo. Per repository particolarmente estesi (si porta come esempio il repository di Chromium che contiene più di 500 mila branch e tag), questo si traduceva nel server che inviava al client decine di MB di dati che, quest’ultimo, semplicemente ignorava.

La nuova versione migliora di 3 volte le performance per questo tipo di operazioni, anche su repository particolarmente grandi. Inoltre si ha una riduzione di 8 volte sui byte non riguardanti reali dati contenenti nei file in gestione al versionamento (non-packfile).

Nonostante Google abbia già migrato tutti i suoi server Git a questo nuovo protocollo, restava da gestire un grosso problema: come mantenere la retrocompatibilità del client con i server che non lo gestiscono. Già perchè il protocollo Git pare sia particolarmente rigido (ne ha gettato le basi Torvalds, sarà un caso?) e l’aggiunta di campi alla richiesta iniziale (ad esempio per richiedere di utilizzare una versione di protocollo rispetto ad un’altra) rompe la compatibilità con la versione precedente.

E’ interessante nell’articolo leggere come è stata sfruttata l’applicazione un fix di un bug introdotto nel 2006, e risolto nel 2009, per utilizzare un comportamento inaspettato del protocollo e di come questo, una volta applicata questa fix, gestisce i byte NUL (\0) ala fine della stringa. Potremmo dire che viene utilizzato, a fin di bene, un bug nella patch, facendo in modo che i server Git compatibili con versioni <2 di protocollo ignorino la stringa, mentre quelli nuovi la possano leggere per capire se il client sta facendo richieste particolari.

Questo protocollo sarà ufficialmente supportato dalla versione 2.18 di Git ma, se volete, potete già provarlo tirando giù il branch master dal repository ufficiale su GitHub.