Il ritardo negli aggiornamenti di Molly solleva timori sulla sicurezza di una libreria di chiamata Signal meno recente
Molly è rimasto tre mesi senza una release stabile elencata, sollevando interrogativi sul fatto che le sue protezioni aggiuntive comportino ritardi nelle correzioni di sicurezza. Il ritardo negli aggiornamenti di Molly merita attenzione perché la release di luglio dichiara una libreria di chiamata precedente alla versione che risolve una vulnerabilità pubblicata relativa alla terminazione delle chiamate.
Al 2 novembre 2026, le prove pubbliche giustificano preoccupazioni su una release datata e una dipendenza potenzialmente interessata. Non dimostrano che aggressori abbiano sfruttato utenti Molly. Né chiariscono se la libreria personalizzata di Molly contenga una correzione equivalente.
La tensione centrale è tra funzionalità di sicurezza aggiuntive e manutenzione tempestiva. Signal fornisce il codice upstream, ovvero il software originale che Molly adatta. Gli utenti di Molly dipendono da un altro processo di rilascio per ricevere tali modifiche. Un fork orientato alla sicurezza, una variante software mantenuta in modo indipendente, deve rendere questo processo affidabile insieme alle proprie protezioni.
Cosa mostra realmente il ritardo negli aggiornamenti di Molly
L'elenco pubblico delle release GitHub di Molly indica v8.19.2-4, datata 31 luglio, come release più recente. Le note descrivono una correzione per una perdita DNS, una divulgazione involontaria delle ricerche di dominio, quando veniva utilizzato un proxy configurato. Ciò colloca la release stabile visibile a oltre tre mesi dalla data di pubblicazione di questo articolo. Lo storico delle release supporta l'affermazione centrale sulle tempistiche.
Il divario tra le release è verificabile; le conseguenze sulla sicurezza richiedono un esame separato.
Questa distinzione è importante perché le date delle release rispondono a una domanda più circoscritta di quanto spesso suggeriscano i titoli. Stabiliscono quando un progetto ha pubblicato un pacchetto attraverso un determinato canale. Non rivelano automaticamente ogni modifica contenuta in quel pacchetto.
Una release meno recente può contenere una correzione di sicurezza importata selettivamente. Gli sviluppatori la chiamano backport: applicare una correzione successiva senza adottare l'intera release più nuova. Al contrario, un pacchetto pubblicato di recente può mantenere una dipendenza obsoleta.
Per i lettori, la domanda utile è quindi più specifica che chiedersi se Molly sembri inattivo. È se l'applicazione installata contenga la correzione per la vulnerabilità in discussione.
La preoccupazione pubblica è emersa attraverso un post della community fornito con il brief di questa storia. Il suo titolo sostiene sia una pausa di tre mesi negli aggiornamenti sia una vulnerabilità. Queste affermazioni dovrebbero seguire percorsi di verifica distinti, anche quando compaiono insieme nel titolo di una discussione.
L'elenco delle release dimostra la prima affermazione. Stabilire la seconda richiede di confrontare i componenti dell'applicazione con una falla documentata, quindi verificare l'esistenza di correzioni equivalenti.
Questo approccio limita anche ciò che si può affermare responsabilmente sul progetto stesso. Una pagina delle release silenziosa non dimostra che i suoi manutentori abbiano abbandonato lo sviluppo. Non spiega la loro disponibilità, i test interni o gli ostacoli al rilascio.
Qui non è stata accertata alcuna spiegazione verificata per la pausa. Attribuirne una trasformerebbe un problema di manutenzione osservabile in speculazione sulle persone responsabili.
Tuttavia, gli utenti non hanno bisogno di una spiegazione per riconoscere che il pacchetto disponibile sta invecchiando. Uno sforzo di sviluppo privato non fornisce alcuna protezione distribuita finché un'applicazione corretta non raggiunge i loro dispositivi.
Ecco perché il divario conta ora. La domanda pratica riguarda il software che le persone possono installare, piuttosto che le intenzioni dietro a lavori che non possono ispezionare.
Per chi segue la vicenda, la data di luglio dovrebbe essere il punto di partenza dell'indagine. Il registro delle dipendenze fornisce l'elemento di prova successivo, e più rilevante.
Una dipendenza di chiamata meno recente rende concreta la preoccupazione
Il codice sorgente associato a Molly v8.19.2-4 dichiara la propria dipendenza Android RingRTC come im.molly:ringrtc-android:2.69.5-1. RingRTC è la libreria software che gestisce le funzionalità di chiamata legate a Signal. La dipendenza di chiamata associata al tag fornisce un componente specifico da esaminare.
Un record di vulnerabilità pubblicato, CVE-2026-113380, identifica un problema di terminazione delle chiamate nelle versioni upstream di RingRTC precedenti alla 2.72.0. Un CVE è un identificatore pubblico utilizzato per tracciare una vulnerabilità divulgata. Il record descrive un'interferenza con l'elaborazione dell'interruzione della chiamata quando un altro partecipante satura una coda interna. L'audio, e forse il video, possono rimanere coinvolti. L'avviso sulla terminazione delle chiamate è stato pubblicato il 20 ottobre.
La dipendenza dichiarata fornisce a questa storia una base tecnica che va oltre l'età dell'applicazione.
Tuttavia, la dipendenza Molly utilizza lo spazio dei nomi dei pacchetti e il suffisso di versione del progetto. Questo crea un importante confine di verifica. Il suo numero la colloca al di sotto della versione upstream corretta, ma il solo numero non dimostra contenuti del codice sorgente identici.
Una valutazione conclusiva esaminerebbe l'esatta libreria utilizzata per compilare l'applicazione distribuita. Determinerebbe se sia presente la correzione pertinente, oppure una modifica funzionalmente equivalente.
Questo articolo non ha completato tale esame a livello di artefatto. Un artefatto è il file software effettivamente distribuito, anziché l'elenco del codice sorgente che descrive come compilarlo.
Le prove supportano quindi una dipendenza potenzialmente interessata e la necessità di chiarimenti. Non supportano la presentazione di un attacco riuscito specifico contro Molly come dimostrato indipendentemente.
La distinzione è utile per gli utenti che valutano chiamate sensibili. Hanno bisogno di una risposta sul componente in esecuzione sui loro telefoni. Una rassicurazione generica sulla crittografia non risponderebbe a questa domanda.
La crittografia end-to-end, che protegge i contenuti tra endpoint comunicanti, non determina da sola se un endpoint smetta di trasmettere quando riceve l'istruzione. Una chiamata può restare crittografata pur comportandosi contrariamente alle aspettative del partecipante.
Si consideri un ricercatore ipotetico che termina un'intervista prima di discutere materiale riservato con qualcuno nelle vicinanze. Il confine della privacy è il momento in cui il microfono smette di inviare audio.
Se questo confine viene meno, una forte protezione durante la trasmissione non ripristina il controllo che l'utente intendeva esercitare. Questo scenario illustra l'importanza della falla segnalata; non è un incidente Molly documentato.
La stessa distinzione conta per le chiamate di lavoro, le interviste alle fonti e le conversazioni personali. Gli utenti prendono decisioni in base al fatto che la partecipazione sia terminata, spesso senza ispezionare lo stato sottostante dell'applicazione.
Per gli sviluppatori, l'onere immediato è specifico. Dimostrare la presenza della correzione risolverebbe più incertezze che confrontare i numeri di versione dell'applicazione o ripetere ampie affermazioni sulla sicurezza.
Il rafforzamento aggiuntivo dipende comunque dalla manutenzione
Molly si descrive come una variante di Signal orientata alla sicurezza. La sua documentazione elenca la protezione con passphrase del database, il blocco automatico, la cancellazione della memoria e alternative per ricevere le notifiche. La stessa documentazione afferma che gli aggiornamenti ordinari arrivano ogni due settimane, con patch di sicurezza applicate quando disponibili. Queste sono le funzionalità e gli impegni di manutenzione dichiarati dal progetto, anziché una verifica indipendente della loro efficacia. I suoi impegni di sicurezza stabiliscono lo standard di cui viene chiesto agli utenti di fidarsi.
Le protezioni aggiuntive e le correzioni tempestive affrontano rischi diversi, e gli utenti devono valutare entrambe separatamente.
Per rafforzamento si intende l'aggiunta di misure destinate a ridurre l'esposizione o a limitare i danni. Un blocco del database, per esempio, riguarda l'accesso alle informazioni memorizzate su un dispositivo. Una correzione della libreria di chiamata riguarda il comportamento durante la comunicazione.
Il successo in un'area non dimostra la sicurezza nell'altra. Un elenco di funzionalità non può rispondere se un particolare componente vulnerabile sia stato corretto.
Questo è il compromesso centrale nella discussione Molly vs Signal. Gli utenti che scelgono un client modificato possono ottenere controlli che apprezzano, accettando al contempo il processo di integrazione e distribuzione di un altro progetto.
Questa dipendenza non rende i fork intrinsecamente insicuri. Significa che il loro profilo di sicurezza include lavoro operativo continuo, accanto alla progettazione delle loro funzionalità aggiuntive.
Una correzione upstream deve essere revisionata, integrata, compilata, testata, firmata e distribuita. La firma associa l'identità di un editore a un pacchetto software affinché i dispositivi possano riconoscere gli aggiornamenti autorizzati.
Ogni fase può essere ragionevole di per sé. Insieme, queste fasi determinano quanto tempo gli utenti attendono prima che una correzione pubblicata diventi una protezione installata.
Il costo è particolarmente rilevante quando le modifiche interessano le stesse aree dello sviluppo upstream. Gli sviluppatori devono preservare le proprie modifiche verificando al contempo che il nuovo codice si comporti correttamente con esse.
Questo lavoro non dovrebbe essere liquidato come un onere amministrativo. L'ingegneria delle release fa parte del confine di sicurezza del prodotto perché gli utenti dipendono dal pacchetto risultante.
Per chi chiede “Molly Signal è sicuro”, la risposta dipende quindi dal rischio considerato. La protezione contro l'accesso occasionale ai messaggi memorizzati è diversa dalla gestione affidabile di partecipanti ostili a una chiamata.
Una valutazione utile chiede quali protezioni siano importanti, quale versione sia installata e quali prove ne supportino lo stato di manutenzione. Un singolo aggettivo non può combinare responsabilmente tali risposte.
Signal principale offre un punto di riferimento perché mantiene l'applicazione originale e la libreria di chiamata. Questa relazione elimina un passaggio di integrazione downstream, sebbene non implichi l'assenza di vulnerabilità.
Molly, nel frattempo, deve giustificare la dipendenza aggiuntiva dalla manutenzione attraverso i vantaggi di cui i suoi utenti hanno effettivamente bisogno. Tale giustificazione diventa più difficile quando lo stato dei componenti rimane incerto.
Il confronto corretto riguarda il comportamento presente e verificabile. Dovrebbe evitare di presumere che un client modificato sia più sicuro perché aggiunge controlli, o che un client originale sia privo di difetti.
La pressione immediata ricade sul processo di rilascio di Molly. Le sue aspettative di manutenzione dichiarate rendono significativa la pausa visibile, indipendentemente dalle ragioni che la determinano.
La correzione upstream cambia la priorità della terminazione delle chiamate
La correzione collegata di RingRTC di Signal aggiunge un flag separato per la richiesta di terminazione e controlla la terminazione indipendentemente dall'elaborazione ordinaria della coda. Un flag è un indicatore di stato memorizzato che il codice può ispezionare direttamente. La modifica introduce inoltre un'attesa limitata e consente alla pulizia di continuare dopo determinati errori. Questi dettagli compaiono nella correzione upstream della terminazione.
Il significato tecnico è la separazione tra la richiesta di terminare una chiamata e l'attesa dietro altro lavoro. La correzione rende la terminazione meno dipendente dal normale avanzamento della coda.
La decisione di un utente di smettere di partecipare necessita di un'applicazione affidabile anche quando un altro partecipante genera attività inattese.
Una coda è una struttura che trattiene il lavoro finché il software non lo elabora. Le code sono comuni e utili, ma il loro ordinamento può diventare rilevante quando azioni locali urgenti condividono l'elaborazione con eventi influenzati da remoto.
In questo caso, la questione di sicurezza riguarda chi controlla effettivamente il ritardo. Il partecipante locale si aspetta che l'applicazione esegua l'azione di riaggancio, anche in condizioni anomale.
Ciò rende il problema diverso da un comune difetto di usabilità. Un’animazione ritardata è scomoda. L’applicazione ritardata di una decisione sulla privacy può esporre informazioni che il partecipante intendeva non divulgare.
La lezione più ampia è un’inferenza ingegneristica derivata da questa correzione. I controlli che interrompono attività sensibili meritano un trattamento esplicito quando il software gestisce input in conflitto o ostili.
Questo principio vale oltre la messaggistica. Un comando di arresto della registrazione, la revoca di una sessione o il ritiro di un’autorizzazione possono comportare aspettative simili. Ognuno richiede una propria revisione dell’implementazione; questa vulnerabilità non dimostra difetti in quegli altri sistemi.
Per questa vicenda, la lezione resta incentrata sulle chiamate. La domanda rilevante è se la libreria distribuita di Molly contenga il comportamento di terminazione introdotto dalla correzione.
Un’interfaccia applicativa più recente non risolverebbe questa questione. Nemmeno il buon esito delle chiamate ordinarie, poiché il normale funzionamento non esercita necessariamente la condizione di errore in esame.
Una convalida utile deve esaminare la condizione anomala stessa. Dovrebbe stabilire che la richiesta locale di terminazione comporta il completamento della pulizia anche quando l’elaborazione ordinaria si blocca o viene sovraccaricata.
Ecco perché una modifica del codice sorgente, un record di build e un controllo di regressione mirato sarebbero insieme persuasivi. Un controllo di regressione verifica che un guasto precedentemente identificato non ricompaia.
Queste forme di prova rispondono a domande diverse. Il codice sorgente stabilisce il comportamento previsto. Il record di build collega quel codice al pacchetto. I test esaminano se il comportamento pertinente funziona.
Gli utenti non dovrebbero dover svolgere personalmente tutta questa analisi. Una dichiarazione del maintainer che identifichi la correzione e le release interessate offrirebbe loro una base pratica per decidere cosa installare.
Il meccanismo spiega anche perché l’età cronologica conta solo indirettamente. Il tempo crea un’opportunità di divergenza, ma la presenza o l’assenza della correzione determina questa specifica preoccupazione tecnica.
Cosa resta non verificato sull’esposizione di Molly
Il record disponibile lascia aperte diverse domande. Questa revisione non ha riprodotto indipendentemente CVE-2026-113380 contro Molly v8.19.2-4. Non ha stabilito se la libreria di chiamata personalizzata di Molly contenga un backport equivalente.
Non ha inoltre stabilito un attacco riuscito contro un utente Molly. Un avviso di vulnerabilità, un’inferenza su un componente interessato e prove di sfruttamento sono conclusioni differenti.
La conclusione più solida supportata dalle prove è un divario documentato tra release, con una specifica preoccupazione irrisolta relativa a un componente.
Questa conclusione è abbastanza seria da giustificare un esame approfondito senza estendersi a dichiarazioni non supportate. Dire che ogni utente Molly è stato monitorato andrebbe ben oltre le prove.
Allo stesso modo, questo problema delle chiamate non dimostra che le cronologie dei messaggi archiviati siano state decrittate. Il meccanismo segnalato riguarda la terminazione di una sessione di comunicazione attiva.
Mantenere l’ambito preciso aiuta gli utenti a prendere decisioni proporzionate. Chi valuta la privacy delle chiamate necessita di informazioni diverse da chi indaga sull’archiviazione dei messaggi o sull’accesso all’account.
La descrizione dell’avviso riguarda un altro partecipante a una chiamata. Non descrive estranei arbitrari che attivano da remoto ogni microfono installato senza un’interazione già esistente.
Questo limite dovrebbe restare visibile ogni volta che la vicenda viene riassunta. Eliminare le condizioni di attacco può far sembrare un avviso più drammatico, rendendolo però meno utile.
L’assenza di un exploit riprodotto specifico per Molly non dovrebbe neppure diventare fonte di rassicurazione. Gli utenti non devono attendere danni pubblici prima di aspettarsi prove che una correzione pertinente sia stata distribuita.
È qui che una risposta prudente a “Molly Signal è sicuro” deve resistere a un verdetto binario. Le prove identificano una domanda su una release e un componente specifici, non un giudizio permanente sul progetto.
Non esiste inoltre alcuna base verificata per attribuire il ritardo a negligenza, finanziamenti, malattia o abbandono. Queste spiegazioni richiedono dichiarazioni o documenti che le stabiliscano.
I maintainer possono affrontare vincoli legittimi, ma gli utenti subiscono comunque le conseguenze di una distribuzione ritardata. Comprendere una causa e valutare una release sono compiti distinti.
Il confronto Molly vs Signal dovrebbe rimanere altrettanto rigoroso. La gestione upstream non garantisce una sicurezza perfetta, mentre un hardening aggiuntivo non giustifica l’incertezza su correzioni note.
Per le organizzazioni, questo suggerisce di valutare build applicative esatte nei flussi di lavoro sensibili. Un nome di prodotto approvato è insufficiente quando client e release diversi contengono software diverso.
Per gli individui, suggerisce di controllare l’applicazione effettiva e il canale di aggiornamento prima di formulare supposizioni. Un’icona rassicurante o un elenco contatti familiare non identificano la dipendenza sottostante.
La risposta più solida ridurrebbe l’incertezza con prove. Un backport documentato indebolirebbe l’inferenza sul componente interessato. Un guasto riproducibile la rafforzerebbe. Entrambi migliorerebbero la discussione.
Tre segnali determineranno se la fiducia si riprenderà
Il divario negli aggiornamenti di Molly sarà più facile da valutare quando i record pubblici collegheranno la correzione pertinente a software che gli utenti possono ottenere. Un altro dibattito sulle preferenze generali in materia di privacy non risolverà quel collegamento.
I prossimi sviluppi utili sono una release corretta, una spiegazione tecnica esplicita e prove di una distribuzione costante.
Il primo segnale è un pacchetto Molly pubblicamente disponibile con una correzione della libreria di chiamata chiaramente documentata. La versione 2.72.0 upstream di RingRTC fornisce una release di riferimento per questa indagine. Può essere rilevante anche un backport equivalente, purché il suo contenuto sia documentato.
Ciò rafforzerebbe la fiducia nel pacchetto specifico affrontando direttamente la questione del componente. Una nuova versione senza informazioni pertinenti sulle dipendenze lascerebbe più lavoro ai revisori.
La distribuzione conta insieme alla pubblicazione. Gli utenti necessitano del pacchetto corretto attraverso il canale che utilizzano effettivamente, con informazioni sufficienti per riconoscere che il cambiamento pertinente è incluso.
Il secondo segnale è una spiegazione del maintainer che identifichi le build interessate e lo stato della correzione. Una simile dichiarazione sarebbe più utile se collegasse modifiche del codice sorgente, identificatori di release e qualsiasi convalida disponibile.
Una dichiarazione che confermi un backport esistente indebolirebbe materialmente l’inferenza secondo cui il pacchetto di luglio conserva questo difetto. Una dichiarazione che confermi l’esposizione chiarirebbe quali utenti devono intervenire.
Entrambi gli esiti migliorerebbero il record pubblico. La specificità tecnica è più preziosa di un’ampia rassicurazione secondo cui la sicurezza resta una priorità.
Il terzo segnale riguarda ciò che accade dopo aver affrontato il problema immediato. Nei prossimi mesi, release regolari e una gestione esplicita delle modifiche di sicurezza mostrerebbero se la distribuzione è tornata affidabile.
Una singola release di recupero può risolvere un problema urgente. Non può, da sola, stabilire come il progetto gestirà la prossima correzione.
Ritardi ripetuti rafforzerebbero la preoccupazione riguardo alla dipendenza dalla manutenzione. Una distribuzione costante indebolirebbe l’argomento secondo cui gli utenti debbano accettare un’incertezza prolungata per mantenere i controlli aggiuntivi di Molly.
Questo segnale finale è importante perché la fiducia implica aspettative sul comportamento futuro. Gli utenti non possono ispezionare oggi il codice di domani, ma possono valutare se un progetto comunica chiaramente e distribuisce correzioni in modo prevedibile.
Per gli sviluppatori che mantengono altri fork incentrati sulla sicurezza, le stesse prove offrono un parametro pratico. Spiegate lo stato dei componenti, identificate i pacchetti interessati e rendete visibile il percorso dalla correzione all’installazione.
Per i lettori, mantenete la decisione ancorata a prove che potete verificare: la versione installata, i suoi componenti documentati e lo stato delle correzioni pertinenti. Evitate di trattare un elenco di funzionalità come sostituto di tale documentazione. Se la privacy delle chiamate è importante per il vostro lavoro o la vostra sicurezza personale, attribuite il giusto peso alle questioni di manutenzione irrisolte quando scegliete un client. Seguite la prossima release e le relative note tecniche, poi riesaminate la decisione quando quei record cambiano. Il divario negli aggiornamenti di Molly solleva una domanda concreta che merita una risposta concreta: l’applicazione sul vostro dispositivo contiene la correzione necessaria per terminare una chiamata in modo affidabile?
