Réseau et sécurité

Whale‑E n’émet que des requêtes HTTPS sortantes, utilisées uniquement pour télécharger des données de marché et vérifier les mises à jour. En dehors de ces deux usages, le logiciel n’établit aucune autre communication réseau. Lors de la vérification des mises à jour, il peut transmettre uniquement un identifiant client pseudonymisé (client_id), que vous pouvez désactiver.

Mises à jour#

Au démarrage, Whale‑E vérifie si une mise à jour est disponible.

Cette vérification passe par updates.whale-e.com. L’URL appelée dépend de la version installée. Par exemple, pour Windows :

https://updates.whale-e.com/releases/whale-e/public/stable/windows-x86_64-msvc/update.json?client_id=<valeur>

Le paramètre client_id est un hash SHA-256 calculé à partir de métadonnées hardware locales. Il nous permet d’estimer le nombre d’utilisateurs actifs à partir d’une approximation par machines uniques. Les valeurs hardware brutes ne sont jamais envoyées.

Si vous ne souhaitez pas envoyer cet identifiant, vous pouvez le désactiver pour une exécution avec --no-update-client-id. Vous pouvez aussi le désactiver via la variable d’environnement WHALEE_UPDATE_CLIENT_ID=0. Les valeurs 0, false, no, off et disabled désactivent l’identifiant. Les valeurs 1, true, yes, on et enabled l’activent.

Quand une version plus récente est détectée, il valide d’abord le manifeste signé. Cette vérification cryptographique garantit que les métadonnées de mise à jour n’ont pas été altérées et qu’elles proviennent d’une clé de signature autorisée.

Le logiciel vérifie ensuite que la mise à jour correspond bien à votre binaire, puis contrôle le fichier téléchargé avec sa taille et son empreinte SHA-256. L’installation n’est effectuée que si toutes les vérifications passent.

Domaines à autoriser#

En connexion directe, le logiciel contacte ces domaines distants en HTTPS sur le port 443. Quand un proxy est configuré, la connexion réseau s’ouvre d’abord vers le proxy, sur son hôte et son port, puis l’accès à ces domaines lui est délégué.

Le tableau liste donc les hôtes distants à autoriser, directement ou via le proxy. Cette liste correspond aux intégrations actuellement supportées.

TLS, proxy et bloc network#

Le proxy et le bloc [network] couvrent deux couches différentes.

Le proxy est une configuration de démarrage. Il est lu uniquement depuis les variables d’environnement héritées par le processus. Cela permet d’utiliser la même configuration proxy pour les téléchargements d’historique et pour les mises à jour, y compris quand l’auto-update démarre avant le chargement complet du fichier de stratégie.

Le bloc [network] est lu dans la stratégie et configure uniquement la politique TLS des requêtes exécutées après le chargement de cette stratégie. Il expose verify_tls, allow_insecure_tls et ca_bundle_path. Il ne configure pas le proxy.

Pour une référence détaillée du bloc, consultez la page Network.

Si vous devez fournir un bundle CA personnalisé dès le démarrage, notamment pour la vérification des mises à jour, utilisez la variable d’environnement WHALEE_CA_BUNDLE. Une fois la stratégie chargée, WHALEE_CA_BUNDLE reste prioritaire sur [network].ca_bundle_path.

Exemple de bloc network:

[network]
verify_tls     = true
ca_bundle_path = "C:/certs/whale-e-ca-bundle.pem"

Configuration du proxy#

Si votre réseau impose un proxy HTTP pour accéder à Internet, le logiciel peut l’utiliser pour les requêtes sortantes. Cela couvre les vérifications et téléchargements de mises à jour, ainsi que les appels API utilisés pour télécharger l’historique des prix et les données de marché des exchanges.

Le proxy ne se configure pas dans le bloc [network].

Les paramètres proxy sont lus depuis les variables d’environnement héritées par le processus qui exécute le logiciel. Ces variables s’appliquent aux requêtes vers les exchanges et aux mises à jour. Pour les requêtes HTTPS, il cherche dans cet ordre : HTTPS_PROXY, https_proxy, HTTP_PROXY, puis http_proxy. Pour les requêtes HTTP, il cherche dans cet ordre : HTTP_PROXY, puis http_proxy. Pour l’exclusion d’hôtes, il lit NO_PROXY, puis no_proxy.

Définissez la variable sur host:port, http://host:port, ou http://user:pass@host:port. Seule l’authentification proxy HTTP Basic est prise en charge. Si une authentification est utilisée, le format attendu est explicitement user:pass@host:port. Un slash terminal vide après host:port reste toléré, mais n’ajoutez ni chemin, ni query string, ni fragment après host:port. Si une variable proxy est définie mais invalide, une erreur explicite est signalée et aucune bascule silencieuse en connexion directe n’est effectuée.

Quand un proxy est configuré, vous pouvez forcer une connexion directe pour certains hôtes. Définissez NO_PROXY comme liste séparée par des virgules.

La comparaison porte uniquement sur les noms d’hôtes. Les ports sont ignorés. Utilisez * pour bypass le proxy partout, un nom exact comme updates.whale-e.com, ou un point en tête pour les sous-domaines comme .whale-e.com. Un point en tête matche les sous-domaines, donc .whale-e.com matche updates.whale-e.com mais pas whale-e.com. Si le proxy perturbe les APIs des exchanges, ajoutez les hôtes concernés dans NO_PROXY.

Windows (natif)#

$proxy = "http://proxy.company.local:3128"
# $proxy = "http://user:pass@proxy.company.local:3128"

$env:HTTPS_PROXY = $proxy
setx HTTPS_PROXY $proxy

$env:HTTPS_PROXY ne s’applique qu’à la session PowerShell courante. setx écrit la valeur pour les nouveaux terminaux, vous devez fermer et rouvrir PowerShell pour qu’elle soit prise en compte.

Les paramètres proxy système Windows ne sont pas lus automatiquement.

setx NO_PROXY "updates.whale-e.com"

Linux Docker#

Les paramètres proxy sont lus depuis les variables d’environnement. Quand vous exécutez le logiciel dans Docker, passez ces variables au conteneur avec docker run -e ...

proxy="http://proxy.company.local:3128"
# proxy="http://user:pass@proxy.company.local:3128"

docker run --rm -it \
  -e HTTPS_PROXY="$proxy" \
  -e NO_PROXY="updates.whale-e.com" \
  -v ~/whale-e-data:/data \
  whale-e