Les opérateurs exploitant BTCPay Server, le logiciel de paiement Bitcoin auto-hébergé, via son déploiement Docker standard doivent sélectionner explicitement Tor lors de leur prochaine configuration ou mise à jour s'ils souhaitent conserver l'accès onion. Ce changement, introduit avec la version 2.4.5, retire Tor des composants automatiquement inclus, transformant un service précédemment intégré en choix de configuration laissé à l'administrateur.

BTCPay a détaillé ce changement de déploiement dans une annonce datée du 5 octobre accompagnant la version 2.4.5, tandis que la page officielle de publication GitHub enregistre la sortie du logiciel le 6 octobre. Pour les installations existantes, le déclencheur pertinent est leur prochaine configuration ou mise à jour Docker — ce qui signifie que le composant peut disparaître d'un déploiement en cours dans le cadre d'une maintenance de routine, à moins que l'opérateur ne le réactive.

Cet ajustement est important pour les opérateurs Docker qui dépendent de Tor, notamment pour l'accès via l'adresse onion de leur serveur — le point de terminaison .onion exposé par les services cachés de Tor — et qui bénéficiaient auparavant du service via le fragment central de BTay Server. Les fragments sont les composants de configuration utilisés pour assembler la pile Docker.

Réactiver Tor après la mise à jour

BTCPay conseille aux administrateurs d'examiner les changements de déploiement avant de mettre à jour. Une fois en version 2.4.5, la commande pour activer Tor est :

sudo btcpay-fragments add opt-add-tor

Tor reste pris en charge, et BTCPay indique que les données existantes demeurent dans les volumes Tor actuels. Cela préserve les données stockées, mais le maintien de l'accès onion dépend toujours de l'inclusion et de l'exécution de Tor dans le déploiement.

Selon la documentation de BTCPay Server, le fragment Tor optionnel opt-add-tor ajoute des services cachés et une connectivité onion sélectionnée. Les opérateurs peuvent inspecter leur configuration avec btcpay-fragments show, une commande qui ne modifie rien et rapporte les fragments supplémentaires et exclus enregistrés ainsi que les fragments effectifs du dernier manifeste généré. Vérifier cette sortie avant la mise à jour, puis après l'ajout du fragment, offre aux administrateurs un enregistrement avant/après de ce que leur pile exécute réellement. Les commandes qui modifient les fragments nécessitent des privilèges root et réappliquent immédiatement la configuration.

Les services privés nécessitent des exceptions distinctes

Les notes de publication de la version 2.4.5 identifient également un changement cassant pour les requêtes HTTP sortantes : les destinations du réseau privé sont bloquées par défaut pour les connexions Lightning, les requêtes LNURL, les URL de notification de factures et les webhooks. Cette restriction vise à prévenir le server-side request forgery (SSRF), une classe de vulnérabilité dans laquelle une application est trompée et envoie des requêtes vers des ressources réseau internes ou restreintes.

Comme les deux changements sont livrés dans la même version, une seule mise à jour peut affecter deux parties distinctes de la configuration d'un opérateur : la disponibilité onion et les appels sortants vers des adresses privées. Avec cette protection activée, les opérateurs qui utilisent intentionnellement des services privés doivent autoriser les destinations requises via ssrfexceptions. Le guide de l'opérateur de BTCPay indique de redémarrer l'application et de tester l'intégration concernée après avoir modifié ce paramètre.