APT peut utiliser SOCKS5h sans wrapper

Les anciennes réponses sur « APT via SOCKS » recommandent souvent un wrapper ou un relais HTTP-vers-SOCKS. Ces réponses peuvent décrire de vraies limites des anciennes versions. Elles ne sont pas la seule option sur une version d’APT qui documente la prise en charge de socks5h.

Un fragment de configuration peut utiliser les clés de transport d’acquisition existantes :

Acquire::http::Proxy "socks5h://127.0.0.1:1080/";
Acquire::https::Proxy "socks5h://127.0.0.1:1080/";

Cet exemple suppose qu’un écouteur SOCKS5 autorisé existe déjà sur la même machine. Il n’en démarre pas. Une redirection dynamique SSH est un moyen de créer cet écouteur local. Si le proxy est distant, utilisez plutôt son point de terminaison réellement joignable ; les candidats de la liste de proxys SOCKS5 ne s’appliquent que là où les proxys publics sont autorisés pour les requêtes du dépôt.

Le schéma fait partie de l’instruction

Le manuel de transport d’APT répertorie socks5h pour SOCKS5 avec résolution DNS distante. Utilisez le schéma documenté pour la version installée au lieu de l’abréger en une étiquette qu’un autre programme accepte par hasard.

De même, Acquire::socks::Proxy dans un ancien extrait de forum ne prouve pas que la méthode d’acquisition HTTP lise ce réglage. Un analyseur de configuration peut accepter une clé sans qu’une méthode de téléchargement l’utilise.

L’adresse locale a une limite

Lorsque APT s’exécute dans un conteneur ou une machine virtuelle, 127.0.0.1 désigne cet environnement. Un écouteur SOCKS sur l’hôte est un autre point de terminaison. Vérifiez où APT s’exécute avant de diagnostiquer une connexion locale refusée.

La prise en charge de SOCKS ne supprime pas non plus les vérifications de signature du dépôt ni de certificat HTTPS. Laissez ces protections activées. Si l’APT installé n’a pas la capacité documentée, choisissez une alternative approuvée ou une voie de mise à jour au lieu de traiter un schéma d’URI non reconnu comme un problème de mot de passe.