Mélodium 0.11 : les secrets dans le langage, les pistes en parallèle
Mélodium 0.11 est disponible. Elle fait évoluer le langage : les identifiants ont désormais leur propre type. Le moteur et ses paquets gagnent aussi en performance, en robustesse et en sécurité. Certains de ces changements cassent des programmes existants : la fin de cet article liste ce qu’il faut mettre à jour.
Les secrets comme type
Les clés d’API, mots de passe et jetons circulaient jusqu’ici dans les programmes sous forme de paramètres string ordinaires, et pouvaient donc se retrouver dans les journaux, les fichiers de debug, les rapports d’exécution ou les arguments d’un processus. Mélodium 0.11 ajoute Secret<T>, le plus souvent utilisé sous la forme Secret<string>.
Un secret contient l’endroit d’où vient sa valeur, pas la valeur elle-même. En ligne de commande comme dans les valeurs par défaut, un paramètre secret prend un localisateur :
treatment main(const db_password: Secret<string> = "env:MELODIUM_SECRET_DB_PASSWORD")melodium run Compo.toml --db_password file:/run/secrets/db_passwordTrois sources existent : env: pour les variables d’environnement, file: pour les fichiers, et vault: pour HashiCorp Vault et OpenBao via le nouveau paquet vault. Les programmes ne voient que les variables d’environnement préfixées par MELODIUM_SECRET_ : celles qui configurent Mélodium lui-même restent hors de leur portée. --check-secrets résout tous les secrets avant le début de l’exécution, pour qu’une variable manquante échoue immédiatement plutôt qu’en cours de route.
Seuls les éléments qui ont besoin d’une valeur la révèlent, au moment où ils l’utilisent. SqlPool lit son mot de passe au moment de se connecter, HttpClient ajoute ses en-têtes secrets à chaque requête, les environnements de processus donnent les secrets aux commandes comme variables ou sur leur entrée standard (jamais dans leurs arguments), et les fournisseurs distants de LLM, de voix et de HuggingFace dans ml prennent leurs clés sous forme de secrets. Chaque révélation est enregistrée comme événement de debug, et les valeurs révélées sont masquées en <secret "name"> dans les messages de journal. Le texte en clair est écrasé dès qu’il n’est plus nécessaire, et avant la fin du processus.
Chaque secret porte aussi une politique : quels éléments peuvent le révéler, s’il peut un jour devenir une donnée ordinaire, et s’il peut quitter le moteur quand le programme est distribué (jamais par défaut, par localisateur seulement, ou par valeur uniquement via TLS). La page Secrets de la documentation couvre l’ensemble.
Vérifier ce que l’on reçoit : le paquet crypto
Les secrets ne sont pas seulement envoyés ; certains sont reçus. Les requêtes HTTP entrantes ne donnent plus leurs en-têtes Authorization et Cookie que sous forme de secrets, et un serveur peut déclarer d’autres en-têtes de la même façon, comme le jeton des webhooks GitLab.
Le nouveau paquet crypto vérifie ces valeurs sans les révéler au programme. Il vérifie les signatures HMAC (SHA-256, SHA-384, SHA-512, SHA-1) et Ed25519, compare des jetons en temps constant, signe et vérifie des JSON Web Tokens, et génère des jetons aléatoires sous forme de secrets.
Une nouvelle étape du tutoriel le montre à l’œuvre : Webhooks signés reçoit des webhooks de GitHub et de GitLab, vérifie la signature HMAC de GitHub et le jeton de GitLab, et ne répond 200 qu’une fois la requête prouvée authentique. Les exemples existants ont aussi été mis à jour : les démonstrations LLM, le tutoriel SQL et le tutoriel de calcul distribué prennent désormais tous leurs identifiants sous forme de secrets.
Passage à smol
Mélodium s’appuie désormais sur smol , en remplacement d’async-std, dont le développement a été arrêté. Le moteur gère lui-même son exécution asynchrone : les pistes et les tâches continues des modèles s’exécutent sur des fils d’exécution qu’il administre, et les signaux Unix sont reçus via async-signal. Toute la bibliothèque standard a suivi : le serveur et le client HTTP reposent sur trillium-smol, SQL sur sqlx 0.9 avec son environnement smol, les fichiers et les processus sur async-fs et async-process, et les fournisseurs distants de ml ainsi que les appels Kubernetes de work s’exécutent dans un contexte Tokio fourni par async-compat.
Comme le moteur maîtrise ses fils d’exécution, les pistes s’exécutent désormais en parallèle, avec un fil par cœur par défaut. Les programmes qui gèrent beaucoup de pistes indépendantes, comme un serveur HTTP qui répond à des requêtes simultanées, utilisent tous les cœurs sans aucune modification de leur code. La variable d’environnement MELODIUM_THREADS fixe un autre nombre de fils d’exécution.
Terminer proprement une exécution
Sous Linux et macOS, SIGINT, SIGTERM et SIGHUP demandent désormais la fin de l’exécution : les pistes en cours disposent de 10 secondes pour se terminer, et un second signal les arrête immédiatement, avec les commandes qu’elles ont lancées. Mélodium se termine avec le code 128 plus le numéro du signal. Sous Windows, Ctrl+C, Ctrl+Break, la fermeture de la console, la déconnexion et l’arrêt de la machine sont gérés au mieux, avec le code de sortie STATUS_CONTROL_C_EXIT. Un programme qui ne peut pas être lancé se termine désormais avec le code 1.
Une distribution plus stricte
melodium dist lit ses clés d’authentification depuis des fichiers (--recv-key-file, --send-key-file) ou depuis les variables d’environnement MELODIUM_DIST_RECV_KEY et MELODIUM_DIST_SEND_KEY. --recv-key et --send-key fonctionnent toujours, avec un avertissement, car les autres utilisateurs locaux peuvent lire les arguments des processus. Le TCP simple (--disable-tls) est désormais refusé sur les adresses autres que celles de bouclage, sauf si --allow-plain-tcp est donné.
Les certificats de distribution ont été renouvelés sous une nouvelle racine, « Mélodium Distribution Root G2 », valide jusqu’en 2036. La racine précédente expire fin décembre 2026 et n’est plus reconnue : tous les moteurs qui participent à une exécution distribuée doivent être en 0.11.
Choisir où s’exécutent les workers
work/distant reçoit un paramètre system pour demander un système d’exploitation, une distribution Linux ou une image machine précise pour un worker. Les architectures couvrent toutes celles de la spécification d’image OCI, les noms propres à Rust (x86_64, aarch64…) sont acceptés comme alias, et |local_arch donne l’architecture de la machine qui exécute le moteur. Le paquet cicd suit : setupRunner prend le même paramètre system, et ses jetons de statut GitHub et GitLab sont des secrets, lus par défaut depuis MELODIUM_SECRET_GITHUB_TOKEN et MELODIUM_SECRET_GITLAB_TOKEN.
Ce qu’il faut mettre à jour
- Identifiants : l’
api_keydeRemoteLlm,RemoteSttetRemoteTts, letokendeHfHubet les clés de|new_accesssont désormais des secrets. Déclarez les paramètres correspondants enSecret<string>, transmettez-les avec|wrap<Secret<string>>(...), et donnez des localisateurs plutôt que des valeurs, commeenv:MELODIUM_SECRET_ANTHROPIC_API_KEY. Les démonstrations mises à jour montrent la démarche. - Serveurs HTTP :
AuthorizationetCookiene figurent plus dans les en-têtes de la requête, seulement dans les secrets de@HttpRequest. - Architectures :
simpleStepet ses variantes ne prennent plusarm64par défaut quandarchest absent ; le conteneur s’exécute sur l’architecture de son worker.|containeret|service_containerprennent une architecture optionnelle, écrite|wrap<Arch>(...). Compose refuse les architectures différentes de celle de l’hôte. - Éditions :
distantn’envoie aucune édition quand le programme n’en donne pas, ce qui signifie que toute édition convient, au lieu descratch. - Appels de fonctions : les appels avec plus de paramètres ou de génériques que la fonction n’en prend sont désormais refusés ; ils étaient auparavant ignorés sans avertissement.
- Rust : compiler Mélodium nécessite Rust 1.94, et les utilisateurs de la bibliothèque trouveront des changements incompatibles dans l’API du moteur (tâches smol, accès aux secrets dans les traitements et les modèles).
Le détail complet pour chaque crate est dans le CHANGELOG . Comme d’habitude, mise à jour via cargo install melodium ou un binaire précompilé.
