Self-hosto Discourse. Tuttavia, non mi piace distribuire versioni instabili (beta o, peggio ancora, basate su test in corso). Sembra però che Discourse includa le correzioni di sicurezza solo in queste versioni instabili. Di conseguenza, gli amministratori di server che preferiscono distribuire esclusivamente versioni stabili rischiano di perdere aggiornamenti di sicurezza potenzialmente critici.
Un esempio recente è la 2.7.0 beta5, che include una correzione di sicurezza. L’ultima versione stabile è stata rilasciata 29 giorni fa (v2.6.3), mentre la versione con la correzione di sicurezza è stata resa disponibile solo con v2.7.0.beta5 (pubblicata 23 giorni fa). Per questo motivo, sul mio cruscotto appare il seguente avviso:
E per ricevere questa correzione di sicurezza non ho altra scelta che aggiornare a una beta…
Discourse è un software eccellente e comprendo che CDCD distribuisca rami instabili (test-passing) ai propri clienti. Tuttavia, aprisco questa discussione per esprimere la preoccupazione che alcuni amministratori di sistema possano perdere aggiornamenti critici…
Con questo, chiedo al team di Discourse di eseguire il backport delle correzioni di sicurezza di media/alta priorità e di rilasciare una versione stabile con tale correzione il prima possibile.
Le build stabili ricevono correzioni di sicurezza quando necessario. Tuttavia, non tutte le correzioni di sicurezza menzionate nelle note di rilascio della versione beta richiedono un backport. Alcune potrebbero essere banali o minori e non giustificare lo sforzo o il rischio di un backport. Altre potrebbero essere di gravità media o critica, ma essere dovute a cambiamenti introdotti in una beta precedente, in modo che la vulnerabilità di sicurezza non esista nella versione stabile.
Nell’esempio corrente tratto dalla versione 2.7.0.beta5, la vulnerabilità poteva essere sfruttata solo in circostanze specifiche, su siti che si erano discostati dalle impostazioni di sicurezza predefinite. Di conseguenza, è stato deciso di non eseguire il backport, a causa del rischio di introdurre bug o modifiche impreviste, che cerchiamo di evitare nel ramo stabile.
Credo che se hai specificato il ramo stable, non verrebbe raccomandato l’aggiornamento.
Molti più siti hanno superato i test rispetto a stable o beta (incluso l’hosting cdck), quindi tests-passed è in un certo senso più sicuro di stable. Per questo motivo, penso che utilizzare stable richieda più lavoro. Detto questo, chi utilizza stable parla spesso bene qui di quanto siano bravi nel backportare le correzioni critiche.