April 2021 - nexa - server-nexa.polito.it

Re: [nexa] Portare a 4 le ore settimanali di Tecnologia nelle scuole medie

by Antonio Iacono

> Con uno sforzo leggermente maggiore (servono ~10 € di accessori) è possibile far scattare negli studenti il meccanismo della competizione: Se poi ci vogliamo proprio "svenare", aggiungiamo altri 15/20 euro e acquistiamo un kit con 45 sensori/accessori (cerca "Geekcreit 45") La Fisica non è una materia particolarmente amata dai ragazzi, specie negli istituti non scientifici. Ma con gli "esperimenti" quanto meno la si può rendere un po' meno noiosa. Uno degli accessori di quel kit è un led a tre colori. Qualche settimana fa ho spiegato ai miei figli lo spettro ottico, la lunghezza d'onda dei colori, ovviamente tutto con Arduino. Un altro accessorio è un piccolo laser. Anche questo usato per costruire, ai fini didattici, una piccola barriera anti-intrusione (un po' come nei cartoni di Lupin alle prese con il furto della collana di diamanti), con tre specchietti e un sensore fotorilevatore. Insomma, così come i RoboMaker o i Lego Mindstorms, anche Arduino e simili si possono usare benissimo nella didattica. Antonio

April 17, 2021

Re: [nexa] Portare a 4 le ore settimanali di Tecnologia nelle scuole medie

by Damiano Verzulli

Aggiungo un paio di mie considerazioni sul dibattito "informatica intangibile" vs. "informatica tangibile" di qualche giorno fa. Da laureato in Scienze dell'Informazione (anno 1995), ho trascorso oltre 20 anni completamente all'interno dell'informatica "intangibile": applicazioni e pagine web, script per la gestione di sistemi, applicazioni "classiche". Per oltre 20 anni, l'unico "feedback" tangibile che avevo dalle mie "creazioni" è stato quasi esclusivamente visivo (le videate) e, in minimissima parte (< 1%) "audio" (tipicamente "suoni" che evidenziassero l'insorgere di "allarmi" particolarmente impattanti sui sistemi che avevo in gestione). ~6 anni fa, dovendo decidere come far realizzare l'impianto elettrico della mia nuova abitazione, decisi che le luci della mia casa --la casa di un signore che per 20 anni aveva lavorato come "programmatore"-- non potevano accendersi attraverso un interruttore "meccanico": una "componente informatica" era imprescindibile. Forte del fatto che gli interruttori "meccanici" fossero gia' scomparsi dall'interno degli autoveicoli (dove --da molti anni-- i "pulsanti" non chiudono un circuito elettrico ma richiedono delle azioni gestite da "centraline" e, nel caso dei fari, "relay") e che non avevo traccia di disastri/problemi/inaffidabilità di questi ultimi, mi sono deciso ad utilizzare lo stesso identico approccio: mettere nelle pareti dei normalissimi "pulsanti" la cui pressione viene rilevata da un oggetto intelligente (un microcontrollore) il quale, a sua volta, "ordina" l'accensione/spegnimento della lampadina attraverso un relay. Ho analizzato le principali soluzioni commerciali (sulle cui brochure è ben evidenziato il termine "domotica") e le ho _SCARTATE_ non solo per gli aspetti economici ma, soprattutto, per le dinamiche di lock-in: in quel periodo, infatti, ho metabolizzato l'idea che --in linea teorica-- da mia moglie mi sarei potuto separare, mentre da un impianto domotico "proprietario" che gestisce le luci di casa, _NO_. Il rapporto con quest'ultimo, quindi, è decisamente più "delicato" rispetto a quello con il proprio partner. I mesi successivi sono stati una continua scoperta: * Arduino [1] e la sua architettura "libera" che ne consente l'acquisto di "cloni" cinesi a prezzi dell'ordine di 5 € (cinque!); * ESP8266 [2] che supporta il wifi nativamente, è completamente/liberamente programmabile e si puo' acquistare a prezzi inferiori ai 5 € (cinque!); * community relativamente "di nicchia" ma comunque molto diffuse in Italia ed all'estero, caratterizzate da uno spirito di "condivisione", di "altruismo", di "crescita costruttiva" tali da rendere il concetto di "open-source" un default del proprio modus-operandi [3] Spendendo meno di 100€ (di cui 50 spesi fra legname, plexiglass, portalampade, lampade e pulsanti) ho allestito il mio primo prototipo: una "scatola" di legno al cui interno c'erano: * due arduino connessi fra loro; * 4 pulsanti, la cui pressione richiede l'accensione/spegnimento di luci; * 4 relay che accendono/spengono 4 lampadine * una presa di corrente (a cui si puo' collegare un abat-jour, ad esempio). e poi, per far funzionare il tutto: * ~150 righe di codice, che facevano si che quando si preme un pulsante, arduino rileva la pressione e chiede al relay di accendere/spegnere la luce associata. La costruzione di questa scatola --per me, che arrivavo da ~15 anni di vita professionale in ambito ICT-- ha rappresentano qualcosa di nuovo e incredibilmente soddisfacente: ricordo molto chiaramente il momento della prima accensione, quando ho dato corrente per "accendere" gli Arduino e poi, il primo "click" sul pulsante, con la prima luce accesa. È una sensazione indescrivibile. Nulla a che vedere con il classico "Hello World!" stampato a video come prima applicazioni su un PC classico. Da allora (~5 anni fa) ho approfondito significativamente tutto l'ecosistema Arduino (e dei microcontrollori) e _NON_ riesco a capacitarmi del fatto che siano sostanzialmente sconosciuti al mondo dell'istruzione. L'ESP8266, ad esempio, ha delle versioni straordinariamente utili per far approcciare gli studenti a queste tecnologie. Il Witty Cloud [4] ad esempio, a fronte dei ~7 € (sette!), include: * un chip wireless programmabile, che puo' comportarsi come "access point" (e quindi essere visto dal cellulare) o "client" (e quindi collegarsi al wireless di casa); * un LED RGB, che puo' essere acceso con una luce di colore programmabile * un sensore di luce, che puo' essere "letto" da applicazioni che, in funzione della luce disponibile, si comportano di conseguenza * una interfaccia USB per essere banalmente collegabile ad un PC, per essere programmato * una interfaccia USB per essere "alimentato" * alcuni PIN che possono essere utilizzati per "pilotare" oggetti esterni (es.: relay o altri sensori) Evidenzio che tale attrezzo (che, ripeto, costa 7€) consente di avere su un banco di scuola un oggetto (lui), che si puo' programmare con il notebook di classe e poi "accendere" semplicemente collegandolo ad un power-bank via USB. E di li, a sperimentare: * il cambiare colore del LED in funzione della luminosita' della stanza; * l'accensione del LED quando si mette un dito sopra al sensore di luminosita'; * il concetto di "energia", semplicemente verificando quanto tempo durano due batterie AA, _CON_ e _SENZA_ wifi "acceso"; * e, per i piu' grandi: o la scelta del colore del LED, via wifi, dal PC di classe; o lo sviluppo di una piccola APP per accendere/spegnere il LED. È veramente difficile immaginare con quanto poco sforzo tutto questo sia fattibile. Con uno sforzo leggermente maggiore (servono ~10 € di accessori) è possibile far scattare negli studenti il meccanismo della competizione: * costruire un "line follower" [5]: una piccola macchinina in grado di muoversi (grazie a due ruote azionate da motori) e che, grazie a tre sensori infrarosso riesce a "mantenersi" su una linea (di fatto, prendete un pavimento chiaro... ci piazzate sopra una lunga striscia di scotch nero (nastro da elettricistia classico)... ci piazzate sopra la macchinina.. e lei va); * chiedere agli studenti di "competere" per vedere chi riesce a costruire la macchina piu' veloce, in grado di fare tutto il circuito nel minor tempo (...e senza incidenti) Questa banale idea consente agli studenti di capire cose fondamentali quali: * accelerazione / frenata: se vai troppo veloce, la macchina non riesce ad avere il tempo di restare sulla linea e... esce di strada; * riuscire a discriminare (algoritmicamente parlando) fra "curve" (dove si deve andar piano) e "rettilinei" (dove si puo' accelerare); * riuscire a organizzarsi per preconfigurare (almeno in parte) il "circuito" * ....tante altre cosettine E per tutti quelli che pensano che si tratti di sciocchezze.... invito a dare un'occhiata a questo video: https://youtu.be/IngelKjmecgnexa@server-nexa.polito.it prestando attenzione attorno a: 01:30, 02:10, 03:33 e soprattutto 04:03 e seguenti Non e' banale (per un "non addetto ai lavori") capire quanti problemi (informatici) devono essere risolti per consentire a quel micro-mouse di fare quello che fa... Certo è che mi piacerebbe che in una qualche finale, prima o poi, ci fosse qualche Italiano/Italiana... Scusate la prolissità. Buona fine settimana, DV [1] https://en.wikipedia.org/wiki/Arduino [2] https://en.wikipedia.org/wiki/ESP8266 [3] http://dvblog.soabit.com/arduino-what-i-missed-most-during-last-ten-years/ [4] https://cutt.ly/1vc0RPs [5] https://www.instructables.com/Line-Follower-Robot-Using-Arduino-2/ -- Damiano Verzulli e-mail: damiano(a)verzulli.it --- possible?ok:while(!possible){open_mindedness++} --- "...I realized that free software would not generate the kind of income that was needed. Maybe in USA or Europe, you may be able to get a well paying job as a free software developer, but not here [in Africa]..." -- Guido Sohne - 1973-2008 http://ole.kenic.or.ke/pipermail/skunkworks/2008-April/005989.html

April 17, 2021

Re: [nexa] Salto di paradigma

by Vincenzo Mario Bruno Giorgino

Caro Antonio, rispondo molto volentieri alle tue domande su quanto è a mia conoscenza. Con un certo ritardo, dovuto al fatto di dover far mente e cuore locali per il mio coinvolgimento su quasi tutti i temi che tocchi nella tua mail. Come fonte prioritaria sul movimento del commoning terrei presente il sito della Fondazione P2P e la rivista *Journal of Peer Production*. Aggiungerei come basi due volumi recenti: Bollier e Helfrich 2015 *Patterns of Commoning,* Off the Commons Books e degli stessi autori 2019 *Free, Fair, and Alive: The Insurgent Power of the Commons* New Society Publishers <https://www.ibs.it/libri-inglese/editori/new-society-publishers>. Ci sono alcuni programmi di ricerca europei conclusi o in corso che si ispirano a questa prospettiva. Ad esempio, posso citarne due di cui ho fatto o faccio, parte: Co-City del Comune di Torino http://www.comune.torino.it/benicomuni/co-city/index.shtml e CO3 ( https://www.projectco3.eu/it/ , in corso), entrambi con coordinamento per la parte accademica di Guido Boella del Dipatimento di Informatica dell'Università di Torino. Molto interessante anche quello in cui è coinvolta Nexa per la parte giuridica: Decode https://decodeproject.eu/ Un altro programma è D-Cent https://dcentproject.eu/ e P2P models https://p2pmodels.eu/ , entrambi conclusi. La lista non è esaustiva... C'è altro e ciò vale solo come spunto. Sono in corso varie esperienze di co-progettazione con l'impiego di tecnologie di archiviazione distribuita che mirano ad un'economia dei commons. Sto facendo una ricerca con il dr. Sowelu Avanzo basata sulla metodologia della grounded theory sul commoning digitale e presto avremo qualche risultato da condividere. Con il gruppo di ricerca WiseLifeLab (Sowelu Avanzo e Giulio Peraldo, più altri collaboratori temporanei), presso il Dipartimento di cui faccio parte, stiamo sviluppando un protocollo per la co-progettazione di ecosistemi ispirati ad un commoning saggio e giusto, chiamato 3S-Social Shield Shaper: una bozza è su GitHub. Esso è in linea con un modello che considera anche le* tecnologie del sé *come basi per la co-progettazione e che mira ad evitare il determinismo, superando la divisione individuo-società, o micro-macro, tipica della sociologia tradizionale. L'intento è proprio quello di rispondere a quell'inquietudine che ti ha portato al filosofo sudcoreano che citi, con la differenza che credo sia meglio superare le barriere accademiche tra discipline e contribuire ad un paradigma transdisciplinare che includa le dimensioni emozionale e sensoriale e tenga conto della nostra impermanenza e riprenda le tradizioni di saggezza, inclusa quelle religiose, in un'ottica laica e non gerarchica (e maschile), ma P2P per così dire. A questo proposito c'è un bel saggio di Michel Bauwens che suggerisco di leggere https://wiki.p2pfoundation.net/Next_Buddha_Will_Be_A_Collective Quest'ultimo punto concilia una rifondazione delle scienze sociali con l'approccio contemplativo, una volta ridefinito in forma non religiosa e con un linguaggio davvero universale e scientificamente accettabile. Dal 1998 mi dedico a questo, curando tre volumi sul tema (se hai interesse ti mando dei capitoli): 1) con Valerie Bentz *Contemplative Social Research*, Fielding University Press del 2016, 2) *The Pursuit of Happiness and the Traditions Wisdom* del 2014 (Springer) e 3) con Z. Walsh *Co-designing Economies in transition*, in cui sono ospitati testi di giuristi, sociologi, economisti e filosofi oltre che informatici. Spero di concludere per l'estate un volume sul *Wise Commoning* per cui ho da tempo un contratto con Palgrave... Inoltre, sempre dal 1998 ho introdotto le pratiche contemplative nei miei corsi di sociologia, presentate come metodi di conoscenza in prima persona, arrivando a fare un corso senza alcuna etichetta disciplinare (sociologica): *Soft Skills and Life Skills in Organizations and Communities*. Purtroppo, pur avendo avuto un buon successo con gli studenti, è durato solo un anno - 2016-2017, essendo stato cancellato senza alcun motivo apparente dal Dipartimento di Management presso il quale si teneva. Qualche tempo dopo lo stesso Dipartimento ha introdotto il corso *Spiritualità e Tecnologie* tenuto da Don Peyron, molto attivo in questa newsletter. Oltre al dispiacere personale che ne ho derivato, mi ha rammaricato e tuttora mi rammarica che una università statale abbia compiuto questa scelta, cancellando un corso a impostazione laica sulla dimensione esistenziale e contemplativa in relazione alle tecnologie digitali, per di più tenuto da un docente di ruolo. A mio parere sarebbe stato giusto e utile mantenerli entrambi. Purtroppo nessun collega ha creduto allora di prendere posizione, non tanto a mia difesa, ma a supporto della visione culturale secolare che era alla base del mio corso. Sono però convinto che, se il progetto ha valore, camminerà lo stesso anche senza di me ed altrove. Lo scrivo qui ed ora in quanto sono prossimo alla pensione, e lascio con una certa amarezza perché la visione di una ricerca transdisciplinare, orientata ad una teoria generativa, di impronta post-costruttivista e non deterministica, cui ho dedicato più di vent'anni, aveva anche l’aspirazione di influire sulle modalità di fare didattica, innovandola alla radice, oltre l’apprendimento ipercognitivo dominante, anche allo scopo di favorire il benessere degli studenti. Non dubito che anche in Italia ci sia una cultura laica che saprà, senza inutili contrapposizioni, trovare il suo spazio ben oltre gli stantii dibattiti tra "scienza e religione". Il successo del movimento della *mindfulness* dovrebbe a questo proposito insegnare qualcosa (allego quattro voci). Spero, Antonio, che a parte la digressione personale, quanto sopra ti sia di qualche utilità. Un saluto, Vincenzo Giorgino Il sab 3 apr 2021, 10:40 Antonio Iacono <antiac(a)gmail.com> ha scritto: > > sono d'accordo con quanto scrivi ma credo che uscire allo scoperto > unendo le sensibilità personali sulla questione andrebbe oltre questa > lista. Essa può essere utile per indicare problemi, lanciare una > discussione, ma nn è un movimento. > > Capisco, quindi una sorta di "comunicazioni agli addetti", una bacheca > di spunti più o meno interessanti, da approfondire altrove o utili ad > arricchire il proprio bagaglio culturale. > Peccato, per un po' ho pensato di trovarmi in una moderna agorà. Il > "medium", la mailing list, è il mezzo di comunicazione che preferisco > in assoluto e la vivavità delle discussioni mi ha portato ad > immaginare un "luogo" in cui gli argomenti, via via proposti, > potessero essere affrontati in tutte le sfaccettature, da più punti di > vista, ognuno, ovviamente con le proprie idee e sensibilità. > Quello che chiedevo nella precedente email era solo questo, una > partecipazione più ampia, non certamente di trasformare questo spazio > gentilmente offerto dal Nexa in una, come si usa dire adesso, "bolla > ideologica" o "camera dell'eco", né in comunità o movimento. > > > Per quello io credo già ci siano delle opportunità, e penso al movimento > dei commons fondato da Bauwens, Bollier ed Helfrich. > > Movimento che negli ultimi anni, purtroppo, sembra arenatosi. Se non è > così, per favore potresti darmi link e riferimenti ad iniziative > recenti? Grazie. > > > Lo scopo è inserire le tecnologie informatiche ed il sapere a loro > connesso in un quadro più articolato, perché nessuna tecnologia è avulsa > dai rapporti sociali. > > Perfettamente d'accordo, ed è proprio per questo che è importante > l'apporto degli "studiosi del sociale". In questi giorni sto leggendo > Byung-Chul Han, un filosofo molto critico nei confronti della rete. > > > E a complicare il quadro c'è un'esigenza di fondo che integra la visione > dominante dei rapporti sociali con una domanda esistenziale, componente > tenuta sinora fuori dalle discipline che se ne occupano - le scienze > sociali - per motivi di affermazione accademica (replicare il successo > delle scienze naturali). > > Scusami, non facendo parte del corpo accademico, questa tua ultima > frase mi è poco chiara, quale è stato il "successo delle scienze > naturali"? > > Antonio >

April 17, 2021

Re: [nexa] Dependency Hell Confusion: Supply Chain Attack

by M. Fioretti

On Sat, Apr 17, 2021 11:38:42 AM +0200, Giovanni Biscuolo wrote: > ... sono fioriti sistemi - uno per ciascun linguaggio di > programmazione (javascript con npm in testa) - che consentono di > caricare qualsiasi software semplicemente aprendo un account in uno > di quegli store io nel computer ho da forse due anni ormai una bozza di post intitolata "the sad state of Linux software packaging" proprio a proposito di questo argomento, perche' e' un delirio. Peggio di quando ti dovevi compilare tutto dai sorgenti, da un certo punto di vista. Devo decidermi a finirla e metterla online. Se avete esempi pratici da fornire, grazie in anticipo. Marco -- Help me to continue my digital awareness blogging: https://stop.zona-m.net/christmas-2020-fundraising/

April 17, 2021

Reproducible Builds: Increasing the Integrity of Software Supply Chains

by Stefano Zacchiroli

Visto che i build riproducibili sono spesso citati in lista, in particolare in relazione agli attacchi alla "software supply chain", mi permetto di segnalare questo articolo di prossima pubblicazione su IEEE Software di cui sono co-autore, sperando di fare cosa gradita. È un articolo sostanzialmente divulgativo sui "reproducible builds" e di come questi aiutino ad aumentare la fiducia nella software supply chain, in particolare per il software libero. Presenta inoltre l'esperienza del progetto Reproducible Builds https://reproducible-builds.org/ nel rendere riproducibile una larghissima parte della distribuzione Debian. L'articolo è destinato ai vari professionisti del software, ma accessibile a chiunque si interessi di software in senso lato. Qua i dettagli bibliografici ed un link ad un preprint open access: Chris Lamb, Stefano Zacchiroli Reproducible Builds: Increasing the Integrity of Software Supply Chains To appear in IEEE Software. IEEE, 2021 https://arxiv.org/abs/2104.06020 Abstract: Although it is possible to increase confidence in Free and Open Source Software (FOSS) by reviewing its source code, trusting code is not the same as trusting its executable counterparts. These are typically built and distributed by third-party vendors, with severe security consequences if their supply chains are compromised. In this paper, we present reproducible builds, an approach that can determine whether generated binaries correspond with their original source code. We first define the problem, and then provide insight into the challenges of making real-world software build in a "reproducible" manner --- this is, when every build generates bit-for-bit identical results. Through the experience of the Reproducible Builds project making the Debian Linux distribution reproducible, we also describe the affinity between reproducibility and quality assurance (QA). A presto -- Stefano Zacchiroli . zack(a)upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »

April 17, 2021

Re: [nexa] Il ruolo dimenticato delle donne nella storia dell'informatica

by Antonio Iacono

> https://www.internazionale.it/notizie/clive-thompson/2021/04/16/donne-infor… "Quando la prima generazione di personal computer – per esempio il Commodore 64 e il Trs-80 – arrivò nelle case, i ragazzi cominciarono a giocarci e, un po’ alla volta, impararono i concetti base della programmazione. A metà degli anni ottanta alcuni dei nuovi iscritti arrivavano all’università sapendo già programmare [...] erano quasi tutti maschi, perché erano stati più a contatto con i computer rispetto alle ragazze. C’era il doppio delle probabilità che ne avessero ricevuto uno in regalo dai genitori, ed era normale che se un computer entrava in casa finisse nella stanza del figlio invece che in quella della figlia. I maschi tendevano anche a collaborare con i padri, studiavano i manuali di linguaggio Basic con loro ed erano incoraggiati a imparare, cosa che non succedeva con le figlie [...] i maschi erano incoraggiati a giocare con le costruzioni e con gli apparecchi elettronici, le femmine a intrattenersi con le bambole e le cucine giocattolo" Ahimé, da adolescente "sinclairista" di quegli anni non posso che confermare. Speriamo di aver chiuso definitivamente con quella "mentalità". Antonio

April 17, 2021

Re: [nexa] Il ruolo dimenticato delle donne nella storia dell'informatica

by Roberto Resoli

Il 17 aprile 2021 12:44:28 CEST, Luigi Scorca <luigi.scorca(a)gmail.com> ha scritto: >https://www.internazionale.it/notizie/clive-thompson/2021/04/16/donne-infor… Bellissimo, grazie. >Luigi

April 17, 2021

Il ruolo dimenticato delle donne nella storia dell'informatica

by Luigi Scorca

https://www.internazionale.it/notizie/clive-thompson/2021/04/16/donne-infor… Luigi

April 17, 2021

humor: Power Users

by Giovanni Biscuolo

Buongiorno, è da anni che tento di capire i veri motivi di situazioni come il "Dependency Confusion" (in reatà di tutta la classe di "Supply Chain Attacks") segnalato poco fa in lista [1] e solo ieri sera ho scoperto l'arcano: tutto dipende dai "Power Users"! https://www.gnu.org/fun/jokes/power.users.html --8<---------------cut here---------------start------------->8--- Power Users never read their "Power User's Guide to ..." books, for the same reason they didn't read the software manuals in the first place. [...] Power Users believe computer salesmen. Power Users will buy ANY program that makes wild promises on the box about increasing productivity. These boxes always look impressive on the bookshelf, beside the "Power User" books and course notes. [...] Power Users unreservedly believe their MicroJerk ProjectMeister when it says the project will be complete at 5pm on the last Friday in September next year, but eighteen months later, they won't believe the Real Programmer who says it'll be done "Real Soon Now (tm)". Power Users believe the ads for 4GLs and Application Generator packages, and think that in two weeks they'll be able to fire all their Real Programmers. (Ha ha ha... remember "The Last One"?) --8<---------------cut here---------------end--------------->8--- Giusto: «increase productivity» *e* «fire all real programmers» [2], ecco qual'è il motivo (lo scopo?) di tutto questo :-D Saluti, Giovanni. [1] https://server-nexa.polito.it/pipermail/nexa/2021-April/021041.html [2] il cugino di uno che conosco che fa il programmatore web in una azienda mi ha confessato che il loro "sales department" è talmente efficiente a vendere che loro non riescono a star dietro col reclutamento di nuovi programmatori :-) P.S.: la pagina umoristica risale presumibilmente all'inizio degli anni '90 ma forse forse le cose oggi non sono molto differenti, mah? -- Giovanni Biscuolo Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché.

April 17, 2021

Dependency Hell Confusion: Supply Chain Attack

by Giovanni Biscuolo

Buongiorno, la notizia è "vecchia" (9 Feb 2021) ma non mi pare passata in lista. Io sono _certo_ che il problema rigrarda tutti noi e mi piacerebbe che - almeno spiritualmente - la cosa sia sentita anche al di fuori dei "ristretti" circoli dei progrrammatori. Simili questioni riguardano _tutti_ perché coinvolgono anche "Developers Italia", anche il GARR, anche i servizi erogati dalla PA, anche le banche... e così via, perché oggi è praticamente impossibile mettere assieme una "web app" senza incappare in simili problemi. Succinta introduzione per chi non sapesse cosa sono "npm", "pip" o "rubygem": sono programmi che servono a installare altri programmi da "stores" dedicati; possono installare intere applicazioni utente oppure - come nei casi descritti nell'articolo - installare librerie utilizzate in altre applicazioni, quindi sono *ampiamente* usate come vettore per un "supply chain attack" per tentare di compromettere interi sistemi, compresi quelli di build del software distribuito attraverso altri canali, tipo quelli degli aggiornamenti ufficiali. Da qualche anno a questa parte, siccome il ciclo di distribuzione "tradizionale" [1] del software è impegnativo e molti sviluppatori non ne vogliono proprio sapere perché devono assolutamente distribuire il software... ieri, sono fioriti sistemi - uno per ciascun linguaggio di programmazione (javascript con npm in testa) - che consentono di caricare qualsiasi software semplicemente aprendo un account in uno di quegli store, dando al proprio pacchetto *qualsiasi* nome ancora disponibile (namespacing what?!?) e distribuendolo ad altri utenti e programmatori in modo da creare una catena intricatissima (dependency hell) di dipendenze tra pacchetti, ciascuno con la propria versione, spesso aggiornati "a manetta" come se non ci fosse un domani (e come se non esistesse proprio la questione del "Trusting Trust" dal 1980 circa). Io pensavo che la situazione fosse già abbastanza malmessa, però l'autore del post che vi inoltro ha illustrato che davvero non c'è limite al peggio e ora non solo esiste il "dependency hell", esiste il... "Dependency Hell Confusion" (sigla coniata da me, distribuita in Public Domain). ...sembra il titolo di un film horror :-D Ovviamente fioccheranno gli howto qui e howto la su come fare lo slalom [2] per evitare di cambiare pista (adottare un sistema decente di distribuzione del software), però questo tipo di problemi è presente *da anni* [3] nel mondo del software libero e non: poco, pochissimo viene fatto per *stroncarlo* definitivamente; cosa ci sara mai di così complesso che lo impedisce?!?! (io ho qualche sospetto e _non_ c'entra con la malizia o i servizi segreti) Se pensate che questo sia un problema solo di alcuni "smanettoni" che mettono insieme codice come hobby nel fine settimana vi sbagliate di grosso perché l'autore del pezzo parla, con discrezione, di colossi "Big Tech" come PayPal, Apple e Microsoft. La cosa divertente è che nel giro di poche ore dalla pubblicazione dell'articolo un sacco di imitatori - probabilmente a caccia di una delle innumerevoli succulente taglie sui bug - si sono precipitati a fare la stessa cosa [4] [5] con 1500 pacchetti npm e 3653 pacchetti pip [6] - subito rimossi dal repository PyPI - in un giorno. Ah, giusto per essere chiari: non è che non ci sia soluzione eh, la soluzione l'hanno "scoperta" anni fa quelli che si occupano, appunto, di distribuzioni software. ...e dopo il mio bello sproloquio, ecco l'articolo in questione: https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610 Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies The Story of a Novel Supply Chain Attack Alex Birsan, 9 Feb 2021 --8<---------------cut here---------------start------------->8--- [...] Results The success rate was simply astonishing. From one-off mistakes made by developers on their own machines, to misconfigured internal or cloud-based build servers, to systemically vulnerable development pipelines, one thing was clear: squatting valid internal package names was a nearly sure-fire method to get into the networks of some of the biggest tech companies out there, gaining remote code execution, and possibly allowing attackers to add backdoors during builds. This type of vulnerability, which I have started calling dependency confusion, was detected inside more than 35 organizations to date, across all three tested programming languages. The vast majority of the affected companies fall into the 1000+ employees category, which most likely reflects the higher prevalence of internal library usage within larger organizations. Due to javascript dependency names being easier to find, almost 75% of all the logged callbacks came from npm packages — but this does not necessarily mean that Python and Ruby are less susceptible to the attack. In fact, despite only being able to identify internal Ruby gem names belonging to eight organizations during my searches, four of these companies turned out to be vulnerable to dependency confusion through RubyGems. One such company is the Canadian e-commerce giant Shopify, whose build system automatically installed a Ruby gem named shopify-cloud only a few hours after I had uploaded it, and then tried to run the code inside it. The Shopify team had a fix ready within a day, and awarded a $30,000 bug bounty for finding the issue. Another $30,000 reward came from Apple, after the code in a Node package which I uploaded to npm in August of 2020 was executed on multiple machines inside its network. The affected projects appeared to be related to Apple’s authentication system, externally known as Apple ID. When I brought up the idea that this bug may have allowed a threat actor to inject backdoors into Apple ID, Apple did not consider that this level of impact accurately represented the issue and stated: Achieving a backdoor in an operational service requires a more complex sequence of events, and is a very specific term that carries additional connotations. However, Apple did confirm that remote code execution on Apple servers would have been achievable by using this npm package technique. [...] --8<---------------cut here---------------end--------------->8--- Saluti, Giovanni. [1] tipo tutte quelle attività noiose che svolgono i mainteiners dei pacchetti delle varie distribuzioni [2] https://github.blog/2021-02-12-avoiding-npm-substitution-attacks/ [3] https://link.springer.com/chapter/10.1007%2F978-3-030-52683-2_2 «Backstabber’s Knife Collection: A Review of Open Source Software Supply Chain Attacks» [4] https://www.bleepingcomputer.com/news/security/copycats-imitate-novel-suppl… [5] https://blog.sonatype.com/pypi-and-npm-flooded-with-over-5000-dependency-co… [6] https://www.theregister.com/2021/03/02/python_pypi_purges/ -- Giovanni Biscuolo Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché.

April 17, 2021