chore(release): v0.7.5
Corrige l'échec silencieux « Accès refusé » à la connexion Windows : wireguard.exe /install|uninstalltunnelservice était lancé sans élévation en misant sur son manifeste UAC natif, qui ne s'auto-déclenche jamais via un appel process-à-process. L'appel tente maintenant sans élévation (compatible avec les ACLs accordées via le bouton dédié), puis retente avec une vraie élévation UAC si le premier essai échoue. Le diagnostic d'élévation est mis à jour pour refléter les deux cas. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
@@ -6,6 +6,14 @@ Ce projet suit le [Versionnage Sémantique](https://semver.org/lang/fr/).
|
||||
|
||||
---
|
||||
|
||||
## [0.7.5] — 2026-09-04
|
||||
|
||||
### Corrigé
|
||||
- **Connexion Windows en échec silencieux sur « Accès refusé ».** `wireguard.exe /installtunnelservice` et `/uninstalltunnelservice` étaient lancés sans élévation en misant sur le manifeste UAC natif de `wireguard.exe` — qui ne s'auto-déclenche que lancé depuis l'explorateur ou via ShellExecute, jamais via l'appel process-à-process utilisé ici. Sans les ACLs du service accordées, la connexion échouait donc directement, sans jamais afficher la moindre invite. L'appel tente maintenant d'abord sans élévation (aucune UAC si les ACLs ont été accordées via le bouton dédié), puis retente avec une véritable élévation UAC (`ShellExecuteEx "runas"`) si le premier essai échoue.
|
||||
- **Diagnostic d'élévation Windows trompeur.** Le panneau Tests & diagnostic annonçait qu'une invite UAC apparaîtrait à chaque connexion sans mentionner que les ACLs accordées au service l'évitent — corrigé pour refléter les deux cas.
|
||||
|
||||
---
|
||||
|
||||
## [0.7.4] — 2026-09-04
|
||||
|
||||
### Ajouté
|
||||
|
||||
Reference in New Issue
Block a user