Tra le caratteristiche principali della distribuzione Debian GNU/Linux (questo il nome completo che andrebbe sempre utilizzato) vi è certamente quella della disponibilità dei software. È raro infatti che per un programma open-source, seppur magari conosciuto da un numero ridotto di utenti, non esiste il corrispettivo pacchetto Debian.
Questa caratteristica, di cui chiaramente beneficiano anche tutte le derivate di Debian stessa, in primis Ubuntu, pone però di fronte al grosso problema sul ciclo di vita di questi pacchetti i quali, essendo molti, possono ad un certo punto della loro esistenza diventare “non mantenuti”.
Come racconta Phoronix il progetto Debian ha settantaquattromila pacchetti all’interno dell’architettura x86_64, una grossa fetta dei quali non viene mantenuta con costanza, o addirittura non presenta aggiornamenti da tempo immemore. Ecco quindi la necessità di definire una strategia per cercare di avere pulizia e sicurezza allo stesso tempo.
L’approccio proposto dallo sviluppatore Helmut Grohne vorrebbe essere più aggressivo rispetto all’attuale, andando ad eliminare tutti quei pacchetti per cui esiste un bug che da almeno un anno senza che sia stata prodotta una nuova release.
A questo identikit al momento rispondono ben trecento pacchetti del repository Debian, quindi il livello di pulizia che verrebbe generato sarebbe quantomeno consistente. Anche perché, come riporta Grohne, il costo di gestione di questi pacchetti è enorme e viene sviscerato nella sua proposta.
L’attuale Debian Project Leader si è detto favorevole ad aprire una discussione sulla tematica:
I would love for this discussion to lead to more aggressive removals that we can agree upon, whether they are automated, semi-automated, or managed by a person processing an automatically generated list (supported by an objective procedure). To use an analogy: I’ve found that every image collection improves with aggressive pruning. Similarly, I’m convinced that Debian will improve if we remove packages that no longer serve our users well.
Mi piacerebbe che trovassimo un accordo in merito a questa discussione sulle rimozioni più aggressive, che siano automatizzate, semi-automatizzate o gestite da una persona che elabora un elenco generato automaticamente (supportato da una procedura oggettiva). Per usare un’analogia: ho scoperto che ogni raccolta di immagini migliora con una potatura aggressiva. Allo stesso modo, sono convinto che Debian migliorerà se rimuoviamo i pacchetti che non servono più bene ai nostri utenti.Pertanto, si potrebbe dire, come il dado sia tratto. Verosimilmente, come sempre accade nel progetto, la discussione verrà tramutata in una Debian General Resolutions (GR), lo strumento formale utilizzato all’interno del progetto Debian per prendere decisioni importanti o risolvere questioni controverse.
Di controversie in questo caso non ce ne sono, ma la questione pacchetti non mantenuti è ormai diventata decisamente importante e servirà a tutelare l’intero progetto oltre che a definire una corretta strategia che possa essere adottata ovunque.
L’aspetto mantenimento è salito prepotentemente alla ribalta recentemente, quando si è parlato della backdoor nei sorgenti di XZ. In quel caso la causa è stata l’appropriamento “in sordina” da parte di un maintainer malevolo dei sorgenti di un software tanto diffuso, ma viene da pensare come la community avrebbe reagito se Debian avesse segnalato la necessità di rimuovere il pacchetto xz poiché affetto da problemi non risolti da più di un anno.
La trasparenza può essere una buona arma per garantire la sicurezza?
Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.
English (US)