Gli operatori che eseguono BTCPay Server, il software di pagamento Bitcoin self-hosted, tramite la sua distribuzione Docker standard dovranno selezionare esplicitamente Tor al prossimo setup o aggiornamento se vogliono mantenere l'accesso onion. La modifica, introdotta con la versione 2.4.5, rimuove Tor dai componenti inclusi automaticamente, trasformando un servizio precedentemente incluso in una scelta di configurazione dell'amministratore.

BTCPay ha illustrato la modifica alla distribuzione in un annuncio datato 5 ottobre che ha accompagnato la versione 2.4.5, mentre la pagina ufficiale del rilascio su GitHub registra il rilascio del software il 6 ottobre. Per le installazioni esistenti, il momento rilevante è il prossimo setup o aggiornamento Docker — il che significa che il componente può uscire da una distribuzione in esecuzione nel corso della normale manutenzione, a meno che l'operatore non lo riattivi.

La modifica è significativa per gli operatori Docker che si affidano a Tor, incluso l'accesso tramite l'indirizzo onion del proprio server — l'endpoint .onion esposto dai hidden service di Tor — e che in precedenza ricevevano il servizio tramite il fragment core di BTCPay Server. I fragment sono i componenti di configurazione utilizzati per assemblare lo stack Docker.

Riattivare Tor dopo l'aggiornamento

BTCPay consiglia agli amministratori di esaminare le modifiche alla distribuzione prima di procedere con l'aggiornamento. Una volta passati alla versione 2.4.5, l'istruzione per abilitare Tor è:

sudo btcpay-fragments add opt-add-tor

Tor resta supportato e BTCPay dichiara che i dati esistenti rimangono nei volumi Tor attuali. Ciò preserva i dati memorizzati, sebbene il mantenimento dell'accesso onion dipenda comunque dall'inclusione e dall'esecuzione di Tor nella distribuzione.

Secondo la documentazione di BTCPay Server, il fragment opzionale Tor opt-add-tor aggiunge hidden service e una connettività onion selezionata. Gli operatori possono ispezionare la propria configurazione tramite btcpay-fragments show, un comando che non modifica nulla e riporta i fragment aggiuntivi ed esclusi salvati insieme ai fragment effettivi dell'ultimo manifest generato. Verificare quell'output prima dell'aggiornamento e di nuovo dopo l'aggiunta del fragment fornisce agli amministratori un confronto prima/dopo di ciò che il loro stack sta effettivamente eseguendo. I comandi che alterano i fragment richiedono privilegi di root e riapplicano immediatamente il setup.

I servizi privati richiedono eccezioni separate

Le note di rilascio della versione 2.4.5 segnalano anche una modifica incompatibile per le richieste HTTP in uscita: le destinazioni di rete privata sono bloccate per impostazione predefinita per le connessioni Lightning, le richieste LNURL, gli URL di notifica delle fatture e i webhook. La restrizione è intesa a prevenire il server-side request forgery (SSRF), una classe di vulnerabilità in cui un'applicazione viene ingannata inviando richieste a risorse di rete interne o altrimenti limitate.

Poiché entrambe le modifiche sono incluse nello stesso rilascio, un singolo aggiornamento può toccare due parti distinte della configurazione di operatore: la disponibilità onion e le chiamate in uscita verso indirizzi privati. Con tale protezione abilitata, gli operatori che utilizzano intenzionalmente servizi privati dovranno consentire le destinazioni necessarie tramite ssrfexceptions. La guida per gli operatori di BTCPay indica di riavviare l'applicazione e testare l'integrazione interessata dopo aver modificato l'impostazione.