Devo creare un nuovo pacchetto snap ogni volta che una dipendenza ottiene un aggiornamento della sicurezza?

Se creo un pacchetto snap con diciamo 5 dipendenze. Devo creare una nuova versione del pacchetto ogni volta che una dipendenza ottiene un aggiornamento (di sicurezza)?

Voglio dire, il vantaggio dei pacchetti .deb è che in Ubuntu / Debian per esempio posso usare una libreria e una volta che quella libreria ottiene un aggiornamento che significa un aggiornamento anche per una parte del mio software. E poiché inviano solo aggiornamenti di sicurezza, posso essere (99%) sicuro che l'aggiornamento della libreria non interromperà l'API in modo che il mio software potrebbe interrompersi.

— Felix Haller
fonte

La risposta breve è sì, è necessario ricostruire lo snap se è necessario aggiornare una dipendenza. Tuttavia, c'è anche una risposta più lunga qui.

Supponi di avere un'applicazione che utilizza SSL (potrebbe essere un software incorporato o un sito Web completo che utilizza Apache). Fai le tue ricerche e usi specifici scambi di chiavi e algoritmi simmetrici. Ora supponiamo che una vulnerabilità di sicurezza sia stata scoperta in SSL e che sia stata rilasciata una nuova versione. Solo perché è una versione di sicurezza non significa che la vulnerabilità patchata fosse in uno degli algoritmi che hai usato. E se non lo fosse? E se, rattoppando quella vulnerabilità in un algoritmo che non hai usato, hai fatto qualcosal'uso era rotto o compromesso (mi è successo di recente con PHP)? Se lo stai raggruppando, puoi effettuare una chiamata per sapere se è necessario eseguire l'aggiornamento in base all'uso. Puoi anche testarlo ampiamente prima di distribuirlo a tutti i tuoi utenti. C'è anche la possibilità che la distribuzione che stai prendendo di mira abbia una versione diversa di SSL che non funziona con il tuo software, in cui il raggruppamento nello snap fornisce un'esperienza comune su tutte le piattaforme.

C'è sicuramente un compromesso tra i vantaggi della condivisione delle dipendenze e i vantaggi di raggrupparli.

— Kyle
fonte

Hai risposto ad alcune domande improvvise di recente, con un certo grado di autorità. Sei un dev? In caso contrario, puoi collegarti a fonti credibili? In tal caso, puoi creare alcune fonti credibili?

— Muru,

(A parte questo: se devo fidarmi del giudizio e della comprensione di ogni sviluppatore sul codice OpenSSL invece che, per esempio, il team di sicurezza canonico o quello dei manutentori Debian che gestiscono OpenSSL da anni, parlare di sicurezza a scatto è un carico di riparo. )

— muru,

Se installi software da uno sviluppatore, ti fidi di quello sviluppatore. La domanda su come gestiscono SSL è un buon esempio: avere una versione corretta di una libreria non ti aiuta se lo sviluppatore dell'app non usa la libreria con saggezza. Ci sono molti esempi di app che hanno una cattiva sicurezza a causa di cattive scelte di algoritmi o di gestione delle chiavi o controllo della firma - niente a che fare con la versione di OpenSSL a cui si collegavano. È saggio capirlo: non ottieni magicamente sicurezza ottenendo una nuova libreria sul tuo sistema.

— Mark Shuttleworth,

Al contrario, se un'app è compromessa, un deb di solito lascerà l'attaccante in tutto il sistema, mentre uno snap no. Nessun sistema è perfetto, ma è ragionevole dire che gli snap sono un utile miglioramento in alcuni casi.

— Mark Shuttleworth,

@MarkShuttleworth Potrei fidarmi di dev X per offrire un'app decente in linguaggio Y, ma potrei non fidarmi di loro per capire se una particolare patch di OpenSSL può causare problemi per loro, e mi sembra, questo è ciò che gli snap richiedono da loro. Questo è un livello di dettaglio tecnico con cui non credo che la maggior parte degli sviluppatori di applicazioni sia a proprio agio, motivo per cui loro (e gli utenti) fanno affidamento su librerie come OpenSSL e distribuzioni come Ubuntu. Certo, non sono nessuno, quindi la mia opinione non conta. (Inoltre, gli snap potrebbero essere limitati, ciò non significa che non gestiscano i dati dell'utente, ...

— Muru,