Le module de thème publie deux palettes derrière les mêmes noms : `apply()`
rebranche `BG`, `TEXT`, `TAB_CSS` sur celle qui est choisie au lancement, et
les cent soixante-dix appels répartis dans l'interface continuent de lire
`theme.BG` sans rien savoir du thème actif. Aucun widget n'a eu à changer —
c'est ce que permettait le passage systématique par `theme.X` à l'usage.
Le choix est lu une seule fois, au démarrage. Les feuilles de style sont
posées dans les constructeurs des fenêtres ; les repeindre à chaud
supposerait de reconstruire celle qui porte l'état du tunnel, ses fils
d'exécution et ses minuteries. Le message de confirmation annonce donc la
prise d'effet au prochain lancement plutôt que de laisser croire le contraire.
Le thème sombre reste le défaut, et rend exactement les mêmes feuilles de
style qu'avant.
Un thème clair n'est pas une inversion, et trois familles de valeurs vivaient
en dur là où elles étaient jusqu'ici invisibles. Dans la feuille de style
commune, les variantes d'état des champs et des boutons étaient des voiles
blancs translucides — c'est-à-dire rien du tout sur un fond clair. Le texte
posé sur un aplat saturé — bouton plein, onglet actif, bandeau, sélection —
portait `TEXT`, qui devient presque noir en thème clair et disparaîtrait sur
l'accent : un jeton distinct le dit, blanc dans les deux thèmes. Enfin le
graphe de bande passante peignait son fond en dur, soit un panneau sombre au
milieu d'une page claire ; ses sept teintes sont devenues des jetons, comme
quatre couleurs de survol de la fenêtre principale.
Deux endroits figeaient par ailleurs le thème au chargement de leur module et
auraient gardé les teintes sombres quel que soit le réglage : la feuille de
style de la fenêtre d'historique, bâtie au niveau du module, et la table
état → couleur du diagnostic, évaluée comme attribut de classe. La première
devient une fonction, la seconde ne retient que la puce et demande la couleur
au thème au moment de l'affichage.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Rien ne rouvrait l'application après une mise à jour. Trois choses y
concouraient : le service lance l'installeur avec `/VERYSILENT`, l'entrée
`[Run]` qui la rouvre porte `skipifsilent` et s'en trouve écartée, et
`RestartApplications=no` laisse le Restart Manager fermer sans rouvrir. Le
service annonçait pourtant qu'elle redémarrerait.
Lui rendre l'entrée `[Run]` n'aurait rien réglé : l'installeur est lancé par
le service, donc en LocalSystem dans la session 0, où l'application se serait
ouverte sans bureau visible et avec les privilèges du système. La relance
revient au service, seul composant capable d'ouvrir un processus dans la
session d'un autre, et que l'installeur redémarre une fois les binaires en
place. Le jeton vient de la session console : l'application repart avec les
droits de l'utilisateur, pas ceux du service.
Le marqueur qui la commande est posé par l'installeur et non par le service :
celui-ci ne saurait qu'avoir lancé un installeur, quand l'installeur sait que
l'installation a abouti. Il porte de surcroît déjà cette correction, si bien
que la première mise à jour en bénéficie — un marqueur écrit par l'ancien
service ne serait apparu qu'à la deuxième. Posé en installation silencieuse
seulement, l'entrée `[Run]` couvrant déjà l'installation manuelle.
L'attente qui devait laisser mourir le service avant la copie ne mesurait par
ailleurs rien : elle demandait à `RenameFile` de renommer le binaire sur
lui-même et tenait l'échec pour un verrou, alors que Windows autorise le
renommage de l'image d'un processus vivant — c'est ce qui rend
`restartreplace` possible — et que `MoveFile` refuse de toute façon une
destination existante. La copie partait donc sur un fichier encore tenu,
échouait, `restartreplace` reportait le remplacement au redémarrage suivant,
et l'installeur s'achevait en annonçant une réussite. L'attente porte
désormais sur la disparition du processus, relevée par `tasklist` — dont le
nom d'image, contrairement aux libellés d'état de `sc.exe`, n'est pas traduit
sur un Windows français.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Un code accepté ne se manifestait que par une ligne de journal, écrite
pendant que la fenêtre de saisie se refermait : rien à l'écran ne distinguait
une validation d'un abandon, et l'échéance obtenue — ce que l'utilisateur
venait précisément de demander — restait invisible. Une confirmation
l'annonce désormais, avec sa date de fin et le temps restant.
Le serveur peut par ailleurs enregistrer l'autorisation sans que le trafic
passe pour autant : la règle de pare-feu peut ne pas s'appliquer, et le
réseau reste alors muet malgré un code accepté. Le client le constate
maintenant en fond, en observant ce qui passe là où le sondage se contente de
demander au serveur ce qu'il a enregistré. `remote_network_reachable` devient
publique pour cela — l'interface l'appelle, et un nom privé traversant la
frontière du module aurait menti sur sa portée.
Corrige au passage un refus qui, au lieu de s'afficher, interrompait le
traitement de la réponse. Contre un serveur antérieur à la v0.3.2, qui exige
encore l'identifiant que ce poste ne transmet plus, `POST /api/session` répond
422 ; le `detail` d'une erreur de validation FastAPI est une liste, non une
phrase, et elle atterrissait telle quelle dans un champ que l'interface passe
ensuite à Qt. Les deux gestionnaires `HTTPError` extrayaient ce champ par les
mêmes quatre lignes : elles deviennent `_error_detail`, qui ne retient qu'une
chaîne et rattrape en plus le corps JSON sans objet, sur lequel `.get` levait
une `AttributeError` non capturée. Le 422 dit désormais quoi faire — mettre le
serveur à jour.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
La production des artefacts Windows tenait en quatre gestes manuels — make
windows, make helper, ISCC, puis le renommage — dont seul le dernier laissait
une trace visible s'il était oublié. L'ordre y était contraint sans que rien
ne le dise : wgsecure.iss source dist\wgsecure.exe et dist\wgsecure-helper.exe
sous leurs noms bruts, si bien que renommer avant de compiler l'installeur
l'aurait fait échouer, ou lui aurait fait embarquer les binaires de la version
précédente.
La cible fixe cet ordre et ajoute la vérification qui manquait : la version
vit dans ce fichier et dans wgsecure.iss, sans rien pour les synchroniser.
Bumper l'un sans l'autre produisait un installeur au mauvais numéro, que
publish ne retrouvait pas. Le contrôle est un prérequis et non une étape de
la recette : placé dans celle-ci, il n'aurait averti qu'après plusieurs
minutes de PyInstaller d'un défaut connu dès la première seconde.
La sortie d'Inno Setup part dans un journal recraché en cas d'échec
seulement : l'afficher noyait le résultat sous les avertissements wow64 de
Wine, la jeter aurait rendu toute panne muette.
Outillage uniquement : aucun changement de comportement de l'application,
donc pas d'incrément de version.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
prepare_quit() attend les threads en cours avant toute destruction, mais sa
liste en oubliait deux : le sondage d'état ajouté en 0.8.6 — ma régression —
et le thread de validation de la fenêtre de saisie, parenté à cette fenêtre
depuis la v0.8.2 et jamais attendu. Fermer la fenêtre de code pendant qu'une
requête est en vol suffisait à avorter le process, ce qui arrive dès que le
serveur tarde. Reproduit avec un serveur qui accepte sans jamais répondre,
puis vérifié corrigé sur les deux chemins.
Le sondage est ramené à 4 s : l'arrêt l'attend désormais, et dix secondes y
seraient une interface figée. Son échec ne coûte rien, contrairement à une
validation ratée qui gâche un code déjà saisi.
Ajoute le temps restant sur la ligne Accès distant, et un repli pour les
serveurs sans GET /api/session : sur un 404, le client observe si le trafic
atteint le réseau distant plutôt que de réclamer un code déjà validé. Un 403
reste une réponse qui fait autorité.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le client tenait pour acquis que l'autorisation ne survivait pas à la chute
du tunnel — un commentaire l'affirmait noir sur blanc. C'est l'inverse : le
serveur autorise l'adresse de tunnel du pair jusqu'à l'échéance enregistrée,
et cette adresse ne change pas d'une reconnexion à l'autre. Se reconnecter
ne révoque rien ; seul le client oubliait, et redemandait un code que le
serveur avait déjà accepté.
Il pose maintenant la question au lieu de la supposer, via GET /api/session
(serveur >= 0.3.0), dès que le tunnel monte : démarrage sur un tunnel déjà
actif, reconnexion automatique, ou avant toute invite de saisie. Le serveur
identifie l'appelant à l'IP source, aucun identifiant ne circule.
Serveur injoignable, réponse illisible ou serveur antérieur à la 0.3.0 ne
valent pas « accès ouvert » : sans information, le client ne conclut rien et
laisse le bouton disponible — le sens sûr, et le comportement de la 0.8.5.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
L'autorisation obtenue auprès du serveur a un terme, mais le client n'en
tenait aucun compte : `access_until`, pourtant renvoyé à chaque validation,
ne servait qu'à composer une ligne de journal. L'accès était marqué ouvert
jusqu'à la chute du tunnel, si bien qu'une fois le délai écoulé l'interface
affichait « Ouvert ✓ » et masquait le bouton comme l'entrée de systray —
laissant l'utilisateur devant un réseau muet, sans issue visible, dans la
situation même que ce bouton existe pour couvrir depuis la v0.8.2.
L'échéance remonte désormais jusqu'à la fenêtre principale, qui la relit
sans jamais la calculer : sa durée est un réglage serveur, que le poste n'a
pas à deviner. Un serveur qui n'en annonce pas laisse l'accès ouvert jusqu'à
la déconnexion, plutôt que de se voir imposer un terme inventé ici.
Corrige au passage l'heure de fin, annoncée en UTC mais présentée comme
locale — deux heures d'avance en été.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le bouton et l'entrée de systray étaient conditionnés à un champ vide par
défaut depuis son introduction en v0.8.0 : un poste tenu en quarantaine par
le serveur n'affichait donc aucun moyen d'en sortir. La saisie ne dépend
plus que de l'état du tunnel ; la fenêtre demande l'identifiant quand il
manque et ne l'enregistre qu'une fois le serveur l'ayant accepté.
L'état « Non géré par le serveur » disparaît au passage : le client
l'affirmait à partir de sa seule configuration locale, sans rien vérifier.
« Non vérifié » est la vérité tant qu'aucun code n'a été validé.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le bouton « Saisir le code d'accès » était créé et placé, mais sous le bord
inférieur : rendre un widget visible ne met pas les layouts à jour dans la
foulée — Qt poste un LayoutRequest traité au tour de boucle suivant. La
fenêtre, de hauteur fixe recalculée à chaque changement de contenu, se
mesurait avant ce traitement et obtenait une hauteur en retard d'un cycle.
Le symptôme était déjà visible dans les tests de la v0.8.2 : la hauteur
montait bien de 258 à 298 px à l'apparition du bouton, mais ne redescendait
jamais à sa disparition. J'avais mis cette asymétrie sur le compte du
backend graphique de test au lieu d'y voir le retard lui-même.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
La fenêtre de saisie ne s'ouvrait qu'une fois, juste après une connexion
manuelle réussie. Un refus, une fenêtre fermée, une reconnexion automatique
— qui n'ouvre volontairement aucune modale — ou l'expiration de
l'autorisation au bout de 12 h laissaient un tunnel monté, un réseau muet
et aucun élément d'interface pour ressaisir un code.
Un bouton sous l'action de connexion et une entrée de systray apparaissent
désormais dès qu'une saisie a un sens : identifiant VPN configuré, tunnel
monté, accès non ouvert.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
La v0.8.0 laissait cohabiter deux vérifications du code à 6 chiffres : la
fenêtre MFA locale, qui contrôlait un code contre un secret détenu par le
poste lui-même — et ne verrouillait donc que sa propre interface — puis la
validation par le serveur, seule à décider de l'accès réseau. L'ancienne
disparaît, avec le secret TOTP qu'elle stockait en clair dans config.json
(effacé au premier lancement) et l'onglet MFA du panneau Administrateur.
La saisie passe par une fenêtre dédiée qui relaie le refus exact du serveur
et laisse réessayer, la requête partant dans un thread pour qu'un serveur
muet ne fige pas l'application. Une ligne « Accès distant » distingue
désormais l'état de l'autorisation de celui du tunnel : monté sans code
validé, celui-ci ne mène nulle part.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`release` enchaînait `clean`, qui supprime tout dist/ — donc les artefacts
Windows compilés sous Wine juste avant, que `publish` est précisément censé
joindre à la release. Seul le binaire Linux est désormais retiré, ce qui
suffit à garantir sa fraîcheur.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Deux changements liés, qui achèvent le déplacement de la sécurité vers
le serveur.
1. Le tunnel n'est plus recréé à chaque connexion. Créer ou supprimer un
service Windows n'est jamais délégable à un utilisateur standard, le
démarrer peut l'être : c'est cette réinstallation systématique qui
imposait une authentification administrateur à chaque connexion ET à
chaque déconnexion. Désormais connect() démarre le service s'il
existe déjà, disconnect() se contente de l'arrêter, et le tunnel
reste installé entre les deux.
Trois voies en cascade pour ce démarrage/arrêt : sc.exe sans
élévation, puis le service wgsecure-helper, puis l'élévation en
dernier recours. Le helper gagne donc deux commandes
(start/stop_tunnel_service). Cette cascade tient quelle que soit la
configuration du poste — le test en session standard a montré que
l'ACL posée sur le service WireGuard ne donne aucun droit sur le
service du tunnel, qui est un objet distinct.
2. Après le montage, l'application demande le code à 6 chiffres et le
fait valider PAR LE SERVEUR (app/core/vpn_session.py). Jusqu'ici le
code était vérifié localement, contre un secret que l'application
détenait : elle validait donc un code qu'elle pouvait produire, et ne
verrouillait que sa propre interface. L'ordre est imposé par le
réseau — l'API n'est joignable que depuis le tunnel, qui sert de
réseau de quarantaine tant que le code n'est pas passé.
L'URL de l'API est déduite de l'adresse du client (10.6.0.6 →
10.6.0.1) faute de valeur explicite : c'est l'adresse du serveur
lui-même, la seule jamais filtrée depuis la quarantaine.
Sans identifiant VPN configuré, l'étape est ignorée : le serveur peut
tourner en mode permissif, où un compte non enrôlé garde son accès, et
imposer la saisie bloquerait des installations qui fonctionnent.
Chemins Linux inchangés (branches is_windows()).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sécurité : la clé privée ne subsiste plus en clair dans %APPDATA%.
Le .conf généré est écrasé puis supprimé dès que wireguard.exe l'a
consommé (il en garde sa propre copie chiffrée DPAPI), et l'import
propose d'effacer le fichier source. Windows uniquement : sous Linux
/etc/wireguard/<iface>.conf reste requis par wg-quick down.
Corrige aussi ImpersonateNamedPipeClient, qui appartient à
win32security et non à win32pipe (vérifié par introspection).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Corrige le refus "chemin de configuration hors du dossier attendu" :
le service exigeait %ProgramData%\WireGuard\ alors que l'app écrit sa
config dans %APPDATA%\WGSecure\ (seul dossier inscriptible par un
utilisateur non-admin). Ce chemin n'étant pas recalculable depuis
LocalSystem, la validation repose désormais sur l'usurpation
d'identité du client du pipe : le fichier doit être ouvrable par
l'appelant lui-même, plus des contrôles structurels sur le nom et le
dossier.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Corrige la cause racine des invites d'authentification persistantes :
le service wgsecure-helper ne démarrait jamais réellement. Lancé par
le SCM (sans commande sur la ligne d'appel), HandleCommandLine() se
contentait d'afficher son aide et de sortir, sans entrer dans le
dispatcher — SvcDoRun n'était donc jamais exécuté, aucun journal
n'était créé, le pipe n'existait jamais, et l'app retombait toujours
sur l'élévation UAC. Bascule sur PrepareToHostSingle() +
StartServiceCtrlDispatcher() quand argv est vide.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Durcit la boucle principale de wgsecure-helper : ne capturait que
pywintypes.error (pas Exception en général) et ne protégeait pas
CloseHandle individuellement dans le nettoyage, si bien qu'une
exception inattendue sur une requête pouvait arrêter tout le
service — expliquant un premier échange réussi (juste après
démarrage) puis un service injoignable ensuite. Gère aussi
ERROR_PIPE_CONNECTED (course normale, pas rare, entre CreateNamedPipe
et ConnectNamedPipe) au lieu de la traiter comme une erreur.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Corrige helper_ipc.py : seul CreateFileW avait des argtypes/restype
ctypes explicites. Sans eux pour ReadFile/WriteFile/CloseHandle, le
HANDLE (pointeur 64 bits) était marshalé comme un entier 32 bits par
défaut et tronqué silencieusement, faisant échouer systématiquement
l'échange avec wgsecure-helper — l'app retombait donc toujours sur
son chemin élevé (2 invites UAC) malgré un service qui tournait et
répondait correctement.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Remplace l'enregistrement du service wgsecure-helper (sc.exe create/
start via [Run]) par un appel Exec()+AddQuotes en Pascal script :
l'échappement de guillemets imbriqués dans la chaîne Parameters
produisait une commande sc.exe invalide, silencieusement, alors que
la même commande fonctionnait lancée à la main. Le service n'était
donc jamais enregistré malgré une installation "réussie".
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Corrige Add-DnsClientNrptRule qui échouait systématiquement : ce
cmdlet n'a pas de paramètre -Name (contrairement à Get-/Set-/
Remove-), résolu comme abréviation ambiguë entre -Namespace/
-NameServers/-NameEncoding. Identification de la règle via -Comment
à la place, comme le nettoyage générique existant. Bénéficie au
chemin élevé classique et au service wgsecure-helper.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Ajoute wgsecure-helper, un service Windows privilégié (LocalSystem)
qui installe/désinstalle le tunnel et pose/retire les règles NRPT
sans invite d'authentification répétée. L'ACL du service WireGuard
(v0.7.6) ne délègue que démarrer/arrêter un tunnel déjà installé,
jamais le créer/supprimer, ce que WGSecure fait pourtant à chaque
connexion/déconnexion — d'où les prompts qui persistaient malgré
v0.7.6-v0.7.11. Corrige aussi le handshake, qui échouait pour la même
raison (wg show sans élévation complète).
Purement additif : l'app retombe sur son chemin élevé existant si le
service est absent (composant optionnel dans l'installeur).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Rend le redémarrage du service WireGuard best-effort dans "Configurer
les permissions" : Restart-Service échoue si un tunnel est actif, ce
qui annulait toute l'opération alors que l'ACL/registre venaient
d'être appliqués avec succès.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Détecte "déjà membre du groupe" via FullyQualifiedErrorId au lieu du
texte anglais du message d'erreur, qui est localisé (le français ne
contenait jamais "already a member", faisant échouer le bouton à
chaque nouvelle tentative une fois le groupe déjà accordé).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Corrige la SDDL invalide (erreur 1804) produite par le fix précédent
quand le service porte une clause S: (SACL/étiquette d'intégrité), et
les accents corrompus dans les messages d'erreur Windows (mauvais
codepage/encodage lors de la capture de sortie).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Corrige l'ACL du service WireGuard (bouton "Configurer les permissions")
qui n'était en réalité jamais posée : la SDDL était lue via
Get-WmiObject.DACL.ToString(), qui ne produit pas de SDDL valide.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- _run_elevated_windows() capture désormais la sortie réelle d'une commande
élevée (fichier temp écrit par le process élevé lui-même) : ShellExecuteEx
runas ne transmet jamais les tubes hérités, donc tout message d'échec
élevé (split-DNS NRPT, install/uninstall du tunnel) restait "erreur
inconnue" jusqu'ici.
- run_privileged_readonly() tente réellement `wg show` sous Windows non élevé
au lieu d'abandonner sans essayer — le handshake ne se peuplait jamais.
- Le bouton "Configurer les permissions" active aussi le mécanisme officiel
WireGuard (LimitedOperatorUI + groupe Network Configuration Operators via
son SID, le nom étant localisé) en plus de l'ACL du service déjà en place.
- Le diagnostic Windows précise désormais que le split-DNS (NRPT) exige
toujours une authentification admin séparée à la connexion/déconnexion,
aucune ACL ne pouvant le déléguer (aucun mécanisme documenté trouvé).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
gitea_release.sh ne sait détecter la version que depuis VERSION,
*/version.py, package.json, pyproject.toml ou Cargo.toml — pas
app/__init__.py utilisé par ce dépôt. Le Makefile connaît déjà
VERSION, autant le lui passer directement.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Enchaîne release (build Linux versionné) puis gitea_release.sh
(BorisSkill) pour taguer et publier sur Gitea, en joignant aussi les
artefacts Windows déjà présents dans dist/ pour la version courante
s'ils existent.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Ajoute un fichier log texte rotatif (wgsecure.log) dans le dossier
applicatif, en complément du journal JSON interne, pour diagnostiquer
un échec (ex. split-DNS) sans dépendre de l'UI. Corrige le panneau
Journal qui coupait les messages longs sans moyen de les lire en
entier (défilement horizontal réactivé + infobulle).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
La version s'affiche déjà dynamiquement depuis app.__version__ ; seul le
contenu curaté (FEATURES) devait suivre les apports réels de la 0.7.4 :
diagnostic du split-DNS et verrouillage des champs après import .conf.
Split-DNS repose désormais sur resolvectl par interface (Linux) et une
règle NRPT complète (Windows), avec diagnostic de résolution distante,
verrouillage des champs après import d'un .conf, et consolidation des
couleurs de l'UI dans theme.py.
- Mise à jour du README avec la version 0.7.3 et le badge
- Mise à jour du CHANGELOG avec les notes de version 0.7.3
- Ajout du Split-DNS dans les fonctionnalités de la page About
Generated by Mistral Vibe.
Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
- Ajout du support complet du split-DNS pour Linux (systemd-resolved) et Windows (NRPT)
- Bouton de configuration des permissions ACL pour WireGuard sous Windows
- Suppression de tous les appels à sc.exe (remplacés par PowerShell + wireguard.exe)
- UAC gérée par wireguard.exe lui-même (pas par WGSecure)
- Infobulles ajoutées sur tous les champs de configuration principaux
- Correction du blocage du handshake lié au redémarrage de systemd-resolved
- Incrémentation de la version à 0.7.3
Generated by Mistral Vibe.
Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
- Supprime tous les appels à sc.exe (remplacés par PowerShell Get-Service + wireguard.exe)
- wireguard.exe appelé via run_command() sous Windows (UAC gérée par son manifeste)
- Supprime le double appel à uninstalltunnelservice (évite l'erreur 'service inexistant')
- Ajoute un bouton dans l'onglet Élévation pour configurer les ACLs du service WireGuard
(permet à un utilisateur standard de gérer ses tunnels sans UAC après configuration admin)
- Incrémente la version à 0.7.2
Generated by Mistral Vibe.
Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
- Nouveau diagnostic : signale un DNS non couvert par les IPs autorisées
sur un tunnel scindé (résolution forcée via une interface qui n'a pas
de route vers ce serveur).
- Corrige le test de connexion, l'analyse DNS et la réparation DNS qui
gelaient l'application (sondes lancées sur le thread graphique).
- Corrige le CHANGELOG absent de l'exécutable compilé (page « À propos »
vide) et le badge de latence bloqué sur « hors ligne » quand l'ICMP est
filtré alors que le tunnel fonctionne.
- wgsecure.iss installe désormais WireGuard for Windows automatiquement.
- CHANGELOG.md n'était pas empaqueté par PyInstaller (datas=[]) et son
chemin, calculé depuis __file__, ne survivait pas à l'extraction
onefile : la page « À propos » restait vide une fois compilée. Le
fichier est désormais embarqué (--add-data) et son chemin bascule sur
sys._MEIPASS en mode frozen.
- Le badge de latence se basait uniquement sur un ping ICMP vers
l'endpoint : de nombreux serveurs/pare-feux le bloquent alors que le
tunnel WireGuard fonctionne, d'où « hors ligne » permanent. Repli sur
l'âge du dernier handshake réel quand l'ICMP échoue.
- wgsecure.iss installe désormais WireGuard for Windows en silencieux
(prérequis manquant jusqu'ici), au même titre que le VC++
Redistributable ; make installer-deps télécharge les deux binaires.
- Instance unique : un second lancement réveille l'instance active.
- Autostart et reconnexion auto activés par défaut (nouvelle installation).
- Page « À propos » refaite en 5 onglets (contenu séparé dans app_info.py).
- Corrige le handshake/RX-TX qui ne s'affichaient plus (wg show sans élévation).
- Corrige le diagnostic sudo trompeur (sondes qui ne matchaient jamais les règles).
- Corrige make setup-sudoers bloqué hors session graphique (pkexec -> sudo), idempotent.
- Corrige le README : Kill Switch inexistant retiré, ordre d'élévation réel documenté.
tuxgyverandClaude Opus 5