Log4j, Log4j...il soffitto tu mi sporc.

Log4j, Log4j...il soffitto tu mi sporc.

Sta facendo scalpore nel mondo IT il nuovo baco di una libreria vastamente usata nel mondo Java, al solo scopo di scrivere stringhe in un file. In pratica anziche' usare fprintf() i nostri eroi si erano inventati un catafalco catastrofico di complessita' enorme, col risultato che ad un certo punto ne hanno perso il controllo.

"I nostri eroi" erano quei "Full Stack Exchange Developers" che quando hanno chiesto come e' meglio loggare si sono sentiti dire "usa log4j, perche' imparare a scrivere stringhe in un file? Potrebbe esploderti il cervello!". Cioe' il programmatore medio di oggi.

Il risultato e' che qualcuno ha scritto un software che per scrivere i logs li interpreta. Fa cose. E se gli dite di loggare una specifica stringa, la interpreta e va a chiamare un server ldap che tra gli attributi gli fornisce del codice da eseguire.

Ma anche cosi', meglio cercare di capire per quale motivo succedera' ancora.

Di per se', si tratta di un software opensource. E in teoria, essendo un software opensource, ci si aspetta che una robusta comunita' di sviluppatori, potendo leggere il codice, corregga facilmente le vulnerabilita'. Come si chiama la robusta comunita' di sviluppatori? Si chiama "Ralph Goers". (https://www.ralphgoers.com/)

La "nutrita comunita' " e' una persona, che fa log4j nel tempo libero, dopo il lavoro.

Wow.

E' pagato per farlo? No. Potrebbe rispondervi "scusate, sono in spiaggia, sono le mie vacanze, torno il mese prossimo, se il mio software non funziona smettete di usarlo finche' non sono tornato". E non ci sarebbe niente di strano.

Non e' la prima volta che succede, e non sara' l'ultima.

Anni fa lo sviluppatore di GPG disse che siccome voleva mangiare tre volte al giorno intendeva trovarsi un lavoro ben pagato, e quindi avrebbe sospeso lo sviluppo del software su cui si basa gran parte della criptazione userspace di Linux. Solo allora alcune aziende si accorsero di avere degli spiccioli e trovarono il modo di pagargli uno stipendio per quel che faceva.

Subito dopo, si scopri' che OpenSSL, l'altra gamba della crittazione opensource, aveva un problema di esploit della memoria. E si scopri' che tutto era fatto da 3 programmatori che lavoravano per OpenBSD, ovviamente non pagati o pagati un cazzo, nel tempo libero.

Allora, il pattern e' chiaro:

Ma sarebbe meglio, per spiegare ANCHE il problema, usare QUESTA immagine:

Perche' questo e' ESATTAMENTE il problema.

Le grandi aziende fanno un uso smodato di software opensource. E non lo fanno perche' sia migliore o perche' sia piu' sicuro: lo fanno perche' NON COSTA NIENTE.

Anziche' comprare licenze i manager dicono "usate linux, e' gratis".

Quando nacque il movimento opensource i programmatori contavano, o speravano, in un modello simile al precedente shareware, cioe' "ad alcuni piacera' e ci manderanno dei soldi, altri contribuiranno a migliorarlo, gli altri lo diffonderanno".

Ma la realta' e' che sono diventati "gli scemi che lavorano gratis". Cosi' puo' succedere che nel cloud di Microsoft la strangrande maggioranza delle macchine virtuali sia fatta da immagini di Linux. Microsoft ci fa miliardi. Qualcuno degli sviluppatori di Linux ha mai visto anche una frazione di quei miliardi? Ovviamente no.

Allora mi direte che ci sono fondazioni che ricevono fior di donazioni dalle grandi aziente, e la mia domanda e': ok. Ma io parlo di programmatori. Ricevono questi soldi?

La risposta e' nella Mozilla Foundation e nel suo bilancio. Se non avete seguito tutta la storia, i soliti managerz sono strapagati mentre i programmatori sono trattati di merda.

Per le aziende, l'opensource e' diventato il mondo ove ci sono dei fessi che lavorano gratis , si fanno trattare di merda e si prendono anche gli insulti se sbagliano, e a loro non costa nulla.

Il risultato sono programmatori sempre meno felici di programmare. Un altro caso fu il programmatore (all'epoca l'unico) di Metallb , che ricevette una minaccia di essere citato per danni se non avesse rimediato ad un baco entro la fine del weekend. E lui rispose che ci lavorava nel tempo libero, che si stava rompendo le palle di gente che credeva di poterlo trattare come uno straccio e che stava pensando di mollare.

Siccome senza metallb meta' degli "esperti di Kubernetes" si sparano in bocca, saltarono fuori altre persone ad aiutarlo e l'azienda in questione ricevette tanto di quell'odio dall'internet che preferirono scusarsi. Ma il punto rimane quello: per molti managerz, il software opensource e' fatto da fessi che lavorano gratis, e siccome lavorano lavorano per te, e siccome lavorano per te li puoi anche trattare come merde.

Questo software faceva una cosa sempliissima: scrivere i log di un applicativo in un certo formato. In un linguaggio c-like, era l'equivalente di fprinf(). Siccome imparare fprintf() e' troppo difficile per la scimmia media, allora tantissimi preferivano usare quello: cosi' e' finito ovunque, o quasi. Morale: un casino.

Porcherie del genere esistono in quasi tutti i linguaggi ormai, e servono principalmente ad evitare che un programmatore faccia la fatica di imparare delle librerie standard che fanno gia' la stessa cosa.

E allora abbiamo:

  • Commons IO
  • Guava
  • JUnit
  • Jackson
  • JAXB
  • AssertJ
  • Hibernate
  • HTTPComponents
  • Xerces2
  • Javassist
  • CgLib
  • Jms
  • MQ
  • Joda (manco le date...)
  • Trove
  • Jsoup
  • Netty/MINA

Ormai quasi tutti i linguaggi hanno questo genere di proliferazione di librerie di terze parti, e ognuna di queste ha origine diversa , un lifecycle diverso, e ovviamente una pari probabilita' di essere "infette".

Cosa sta andando storto?

Beh, succede questo. Immaginate di essere una donna. Dovete fare un figlio. Arriva il manager e dice "ci hanno tagliato il budget. da oggi i figli si fanno in 8 mesi". Ora, con la nuova tecnica di taglio cesareo a basso costo, e' abbastanza fattibile. Non e' bello, ma e' fattibile.

L'anno dopo stessa cosa. Adesso bisogna farlo in 7 mesi. Ancora una volta, con un pochino di incubatrice e il taglio, si puo' fare.

Ma a furia di "aumentare la produttivita' semplicemente promettendo al cliente tempi piu' stretti", e' successo che la nostra donna andra' negli orfanotrofi a rifornirsi di bambini.

Se un tempo il manager credeva che nove donne potessero fare un figlio in un mese, oggi qualcuno li ha convinti che UNA donna possa fare un figlio in un mese se fa DevOps, ha una CI/CD, e il figlio e' opensource.

In pratica, si chiede ad UN programmatore di lavorare in parallelo.

Fatto questo, i programmatori non fanno altro che scaricare librerie. Complice anche una certa mancanza di creativita' delle aziende, che chiedono tutte la stessa cosa allo stesso modo.

I tempi di progetto sono calcolati con una tale strafottenza e superficialita' che oggi chiederebbero a Dio di fare l'universo in tre giorni. E no, "Agile/Scrum" ha solo peggiorato la situazione.

Questa continua compressione dei costi senza che esistano DAVVERO tecnologie per rendere lo sviluppo piu' produttivo fa si che la strategia piu' seguita sia quella di riutilizzare software scritto da altri. E gratuito.

Col risultato che passeremo i prossimi 15 anni, mano a mano che l' IT diventa piu' cruciale e usato per cose davvero importanti, a scoprire quanti errori e quanti problemi di sicurezza derivano dall'adozione cieca di librerie che si, saranno anche opensource, ma nessun programmatore ha mai esaminato a fondo PERCHE' NON AVEVA TEMPO.

I prossimi 15 anni di adozione di tecnologie IT saranno un periodo di periodiche fughe di dati, hackers che penetrano sistemi, aumento esponenziale delle spese nel settore della cybersicurezza, ransomware ed altro.

Perche' non esiste il pasto gratis, e se risparmi un mese nel tuo progetto usando una libreria che scarichi gratis, prima o poi ti costera' esattamente quella cifra rimediare ai difetti di quella libreria.