Backdoor nelle librerie xz

Ciao a tutti. Non so se questo è il posto giusto per affrontare questo genere di discorsi, eventualmente chiudete o cancellate il thread.

Sicuramente avrete sentito parlare della backdoor trovata all’interno del pacchetto xz-ultils, infilata da uno degli sviluppatori più attivi del progetto e quindi “fidato”.

L’impatto di questo tipo di compromissione è potenzialmente distruttivo per tutto il software libero, che si basa fortemente sulla fiducia. Come ha ribadito anche Jeremy Soller, uno dei principali sviluppatori di System76, questa modalità di attacco può essere replicata su qualsiasi progetto e ulteriormente raffinata per passare inosservata.

Si torna quindi a parlare della necessità di pagare adeguatamente i maintainer dei software open source più piccoli, che altrimenti rischiano di trascurare i loro progetti aprendo la strada a questa tipologia di sabotaggio.

Qualcuno aveva proposto che fossero le grandi aziende, che guadagnano miliardi sfruttando il software libero, a dover versare una sorta di canone “unico” da distribuire poi agli sviluppatori indipendenti. Voi come la pensate in merito?

2 Likes

In realtà la narrazione lá fuori è fuorviante: a basarsi totalmente sulla fiducia è il software proprietario poichè non può essere verificato (se non con sforzi relativamente disumani).

Il software libero, invece, si basa sulla totale trasparenza. Chiunque può verificare un software libero, e così è stato.

Meme rilevante:

https://redd.it/1bs57jl

Una tassa planetaria sarebbe forse utile per aiutare i “beni comuni”? non saprei, ma qualcosa mi dice che non avrebbe risolto questo specifico problema. Forse dovremmo evitare di scambiarci tarball fatti a mano, nel 2024. Ed, essere anche più partecipi nelle nostre community. Fare triage sui bug, condividere un commento nelle code review, guardare i change log, tradurre; in grande? pagare auditing esterni e indipendenti se un qualsiasi software è adottato in un settore critico (come fa Wikimedia Foundation), ecc. e, sì, perché no, donare :slight_smile: o comunque acquistare servizi di assistenza dall’azienda principale dietro a quel software libero (se esiste).

Ciao e buon software libero :slight_smile:

Secondo me sì, è da un po’ che ci penso

Che se tutti coloro che lavorano con componenti open source (che sono tanti, ma proprio tanti) destinassero l’1% del proprio fatturato ai progetti che adoperano per mestiere, come proposto da ILS e come io stesso faccio da anni, avremmo risolto gran parte del problema (almeno quello economico).

Additare sempre solo ed esclusivamente “le grandi aziende che guadagnano milioni” è la classica scusa per non fare ciascuno la propria parte.

2 Likes

Ne parlavo nel mio podcast e probabilmente ne parlerò nella prossima edizione del mio libro sul foss.

Detto questo:

  • il fatto che il progetto fosse seguito da un mantainer solo come hobby ci segnala la fragilità dell’ecosistema
  • che basta un po di pressione su questa persone per far diventare qualcuno un nuovo maintainer
  • che si dà troppa fiducia all’anonimato e alla buona volontà delle persone
  • i soldi senza un azienda dietro o una persona veramente motivata con fondi sono fondamentali
    • i progetti alcune volte hanno delle aziende di consulenza che vengono pagate per contribuire vedasi Collabora o KDAB

Una tassa non avrebbe senso a livello mondiale, ci si ritrova dietro al chi li gestisce questi soldi? e quanto è giusto darne a uno o a un altro?

Abbiamo la free software conservancy che fa da ombrello a molti progetti, praticamente loro ricevono i soldi per conto tuo e te li girano tutti. Però questi sono progetti strutturati, i problemi li abbiamo solitamente in quelli che non lo sono.

infatti concordo, tutti noi dovremmo fare la nostra parte aiutando i progetti che usiamo.
Pero poi ci sono progetti che usiamo senza accorgercene Enforcing the pyramid of Open Source | daniel.haxx.se

L’ideale è che i progetti si debbano strutturare senza un solo al commando. Di solito i progetti che muoiono non solo seguiti da un singolo ma anche più di uno non attivo o che non risponde.

Certo, ed è il motivo per cui - nell’identificare ogni anno i progetti cui distribuire i miei profitti - adopero composer fund (doc) e npm fund (doc) per avere l’intero albero delle dipendenze (rispettivamente: PHP e JS, che è la roba con cui lavoro). Tra le donazioni erogate quest’anno, nel paragrafo “dipendenze indirette e supply chain”, ci sono diversi pacchetti che manco so cosa facciano, ma sono dipendenze di quel che adopero io e dunque meritevoli di qualche soldo.

Purtroppo, non tutti gli stack offrono la stessa semplicità nell’identificare rapidamente a chi e come donare. Ad esempio, Luis Villa sottolinea la difficoltà nel gestire questa cosa sullo stack C/C++.
Sarebbe molto bello se esistesse un comando apt fund che mi desse tutti gli URL presso cui cacciare dei soldi per i pacchetti che ho installato sul mio PC e sui miei server, inclusi ovviamente quelli che sono stati installati come dipendenza di qualcos’altro.

Non credo neanche che sia questo il problema: una buona maggioranza dei progetti cui dono ogni anno sono delle “one-man band” il cui maintainer ha avuto lo scrupolo di segnalare nel proprio pacchetto un link alla propria pagina GitHub Sponsor o direttamente al proprio PayPal.
Anche senza scomodare fondazioni, organizzazioni, o banalmente OpenCollective, i modi per far arrivare dei quattrini a chi di dovere ci sono (e, semmai, sarebbe utile sensibilizzare i maintainer per attrezzarsi per ricevere anche solo un semplice versamento PayPal).