Zenbleed, le nuove patch in AlmaLinux senza RHEL, le patch altrui in CentOS Stream e… Una provocazione.

Dopo la dichiarazione dello stop alla conformità 1:1 verso Red Hat Enterprise Linux, la nuova gestione dei sorgenti e dell’integrazione delle patch di AlmaLinux aspettava di essere messa alla prova e la pubblicazione della vulnerabilità chiamata Zenbleed (un problema che affligge le CPU AMD Zen 2) ha rappresentato l’occasione perfetta.

Come raccontato nell’articolo Testers needed: Zenbleed patch for AlmaLinux 8 and 9 la patch al problema è stata pescata direttamente da upstream, precisamente dal repository linux-firmware e poi inserita nei repository presso git.almalinux.org.

Al di là della patch in sé, che ha valenza principalmente per via del fatto che la vulnerabilità non è considerata banale, ciò che è molto rappresentativo risiede proprio nella richiesta di tester per la stessa. Qui si gioca tutta la differenza nella gestione dei pacchetti di AlmaLinux rispetto a RHEL, per forza di cose limitata in termini di numeri.

Per capire quindi se ci saranno regression o altre problematiche indotte dall’applicazione della patch ecco quindi la chiamata alle armi verso la community, con relativo dettaglio per l’effettuazione pratica del test.

Il tutto va a braccetto con un’altra vicenda che ha coinvolto sempre AlmaLinux, la quale stavolta è stata promotrice dell’applicazione di una patch verso RHEL, trovandosi quella che possiamo definire una porta in faccia. Come infatti racconta ZDNet, Jonathan Wright, Infrastructure Team Leader di AlmaLinux, a recentemente proposto una fix in CentOS Stream relativa alla CVE-2023-38403, un problema di memory overflow nel tool iperf3, ma essendo le regole relative alle patch proposte molto stringenti (nella pratica è necessario che l’applicazione della patch sia un’esigenza di un cliente) si è ritrovato, inizialmente, ignorato:

Thanks for the contribution. At this time we don’t plan to address this in RHEL but we will keep it open for evaluation based on customer feedback.

A gettare acqua sul fuoco ci ha pensato Mike McGrath, Red Hat VP of Core Platforms (quindi il Signor RHEL), che in un post su Reddit ha spiegato come certamente si poteva agire meglio in quest’occasione, ma ha aggiunto anche un aspetto molto rilevante che parecchi ignorano: il contributo al codice è forse il 25-50% dell’effettivo lavoro svolto da Red Hat. A questo si aggiunge tutta la parte di QE, la certificazione e la garanzia di non avere regression sulle nuove versioni e molto altro, lavori che vengono svolti da circa un migliaio di dipendenti Red Hat.

Ecco dove sta la differenza tra una distribuzione commerciale come RHEL ed una distribuzione community come AlmaLinux, ed ecco perché non sarà automatico per nessun contributore, AlmaLinux o altri, andare ad agire direttamente su CentOS Stream. Ma il punto cardine del discorso è che non lo è mai stato. Il processo di inclusione delle patch è sempre stato regolato da questi presupposti.

Il ragionamento che voglio proporre con questo articolo si conclude con una domanda, che sarebbe interessante ognuno si ponesse nel riflettere su quanto successo nelle ultime settimane: era davvero necessaria la mossa di Red Hat per far prendere coscienza al mercato di quale sia il valore aggiunto nell’acquistare subscription?

Estremizzando: è stata l’incompetenza media a provocare una scelta così netta da parte di Red Hat? In altre parole, è colpa nostra?