Secrets du dépôt

En Parlant~ utilise GitHub Actions pour compiler les binaires de release pour Windows, macOS et Linux. Le pipeline CI a besoin d’identifiants pour la signature du code, la signature des mises à jour, l’analyse antivirus et l’URL du relais multijoueur. Ceux-ci sont stockés en tant que secrets de dépôt GitHub — des valeurs chiffrées que GitHub injecte dans les exécutions de workflows mais n’affiche jamais.

Si vous forkez En Parlant~ et souhaitez produire vos propres builds signés, vous devrez configurer vos propres secrets. Les builds compileront toujours sans eux, mais les binaires ne seront pas signés, les mises à jour ne seront pas vérifiées, et l’étape d’analyse VirusTotal sera ignorée.

Les secrets

Azure Trusted Signing (signature du code Windows)

Les utilisateurs Windows reçoivent un avertissement SmartScreen (« Windows a protégé votre ordinateur ») lorsqu’ils exécutent un .exe non signé. La signature du code élimine cet avertissement et indique à Windows que le binaire provient d’un éditeur vérifié.

En Parlant~ utilise Azure Trusted Signing pour cela. Le build Tauri invoque trusted-signing-cli lors de l’étape de build Windows, qui communique avec Azure pour signer l’exécutable.

Secret	Fonction
`AZURE_CLIENT_ID`	ID d’application du principal de service
`AZURE_CLIENT_SECRET`	Identifiant du principal de service
`AZURE_TENANT_ID`	Tenant Azure AD
`AZURE_SUBSCRIPTION_ID`	Abonnement Azure
`AZURE_CODE_SIGNING_ACCOUNT`	Nom du compte Trusted Signing
`AZURE_CODE_SIGNING_ENDPOINT`	URL du point de terminaison Trusted Signing
`AZURE_CODE_SIGNING_PROFILE`	Nom du profil de certificat

Pour configurer le vôtre : Créez un compte Azure, configurez une ressource Trusted Signing, créez un profil de certificat et enregistrez un principal de service avec les permissions appropriées. Le guide de démarrage rapide Trusted Signing de Microsoft détaille la procédure.

Si vous passez cette étape : Les builds Windows fonctionnent toujours, mais vos utilisateurs seront accueillis par le redoutable écran bleu SmartScreen de la mort — vous voyez lequel. Nous avons tous cliqué sur « Exécuter quand même » en croisant les doigts. Les builds macOS et Linux ne sont pas affectés.

Signature des mises à jour Tauri

Le système de mise à jour intégré de Tauri vérifie que les mises à jour proviennent du véritable éditeur, et non d’une source falsifiée. Lorsque l’application vérifie la disponibilité d’une nouvelle version, elle télécharge la mise à jour et vérifie sa signature par rapport à une clé publique intégrée dans l’application. La clé privée qui crée ces signatures réside dans le CI.

Secret	Fonction
`TAURI_PRIVATE_KEY`	Clé privée Ed25519 pour la signature des mises à jour
`TAURI_KEY_PASSWORD`	Mot de passe protégeant la clé privée

Pour configurer le vôtre : Générez une paire de clés avec pnpm tauri signer generate. Placez la clé privée et le mot de passe dans les secrets de votre dépôt, et la clé publique dans tauri.conf.json sous plugins.updater.pubkey.

Si vous passez cette étape : L’application se compile correctement, mais la mise à jour automatique ne fonctionnera pas. Les utilisateurs devront télécharger les nouvelles versions manuellement.

VirusTotal

Après la compilation des artefacts de release, le pipeline CI téléverse chaque binaire (.exe, .dmg, .deb, .rpm, .AppImage) sur VirusTotal pour une analyse automatisée des logiciels malveillants. C’est un signal de confiance — les utilisateurs peuvent vérifier que les builds officiels sont sains.

Secret	Fonction
`VIRUSTOTAL_API_KEY`	Clé API pour l’API v3 de VirusTotal

Pour configurer le vôtre : Créez un compte VirusTotal gratuit et copiez votre clé API depuis votre profil.

Si vous passez cette étape : L’étape d’analyse VirusTotal échoue silencieusement. Les builds réussissent et sont publiés normalement — vous n’aurez simplement pas de résultats d’analyse automatisés.

URL du relais multijoueur

L’URL du serveur relais multijoueur est injectée au moment du build afin que l’application sache où se connecter pour les parties en ligne.

Secret	Fonction
`VITE_RELAY_URL`	URL WebSocket du relais multijoueur (par ex., `wss://your-relay.fly.dev`)

Pour configurer le vôtre : Déployez votre propre serveur relais (voir le guide de configuration du serveur multijoueur) et définissez cette valeur sur son URL publique.

Si vous passez cette étape : Le multijoueur fonctionne toujours si vous définissez l’URL du relais dans les paramètres de l’application au moment de l’exécution. Ce secret définit simplement la valeur par défaut afin que les utilisateurs n’aient pas à la configurer manuellement.

Résumé

Groupe de secrets	Nécessaire pour	Peut-on s’en passer ?
Azure (7 secrets)	Builds Windows signés	Oui — les builds fonctionnent, les utilisateurs reçoivent l’avertissement SmartScreen
Tauri (2 secrets)	Mise à jour automatique	Oui — les builds fonctionnent, pas de mise à jour automatique
VirusTotal (1 secret)	Rapports d’analyse de logiciels malveillants	Oui — les builds fonctionnent, pas de résultats d’analyse
URL du relais (1 secret)	Serveur multijoueur par défaut	Oui — les utilisateurs peuvent le définir dans les paramètres de l’application

Aucun de ces secrets n’est nécessaire pour compiler et exécuter l’application localement. Ils ne sont pertinents que pour les builds de release CI/CD.