chmod(0o600) n'a aucun effet sur les permissions NTFS reelles : sous Windows, une cle privee generee restait accessible a tout compte ayant acces au dossier (permissions heritees usuelles : Users/Authenticated Users). app/security/key_protection.py : protect_private_key() verrouille l'ACL du fichier via icacls (/inheritance:r puis /grant:r <utilisateur>:F), plutot que d'ajouter une dependance pywin32 - plus lourde a empaqueter avec PyInstaller pour un simple changement de permissions. Repli chmod(0o600) sous Linux/macOS. Echec silencieux (icacls absent, systeme de fichiers sans ACL...), comme le faisait deja l'appel chmod qu'elle remplace. Branchee dans KeyManager.generate_key() (cf commit suivant). Non appliquee a import_key() : une cle importee pointe potentiellement vers un chemin hors du controle de l'application (~/.ssh partage avec d'autres outils), et la consigne est de ne jamais rendre une cle moins accessible qu'elle ne l'etait - ni, par prudence, de modifier sans le demander des permissions definies par l'utilisateur lui-meme. Verifie manuellement avec icacls apres generation reelle : seul le compte Windows courant apparait dans l'ACL du fichier. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
0 B
0 B
The file is empty.