Par ailleurs, ceci permet de ne pas conserver le mot de passe dans le
presse-papier, puisque celui-ci est réinitialisé à la chaine de
caractère vide par la suite.

On enlève le path complet, pour gpg (/usr/bin..), on le remplcae par 'gpg'

 * Par exemple, si le fichier n'est pas chiffré pour ma clef.

On ne gère la conversion vers du binaire (utf-8) qu'au dernier
moment.

La doc de GPG prétend que --with-colons output de l'UTF-8
regardless of any --display-charset. Eh bah c'est faux.

Je provide même un working example :
gpg --list-key --with-colons 095D9EC8C995AB203DC260FEECAA37C45C7E48CE

Actual new target roles were not correctly shown in the editor. (Although the
list of new recipients was correct).

Fix it. Like 88c699e4

Text files always have a final "\n" character. Add it before
running the editor, otherwise, it will automatically add it and we would
think the file has changed.

http://docs.python.org/2/library/subprocess.html#subprocess.Popen.wait

Je n'avais pas lu le warning ...

Autre manière de sélectionner les mots de passes à rechiffrer : on sélectionne
les mots de passes dont la liste des rôle est inclue dans la liste souhaitée.

encrypt ne renvoie plus une chaîne chiffrée mais une liste (sic)
[success, chaîne] depuis 0bdf2035.
On corrige ici pour éviter de defacer tous les mdps.

Lorsqu'on éditait un fichier, on écrasait nécessairement les roles
en place, car l'option.roles était parsée avec la supposition que
None = mes roles en écritures.
On corrige parse_roles en considérant (par défaut) que la valeur None
reste à None, ce qui permet de continuer à vérifier que les arguments
fournis sont valides.
Un peu de refactoring dans le code de edit_file a eu lieu au passage
(principalement des simplifications du code).

C'était plus pratique que de faire un merge de la branche devel-keep-alive.
La feature n'est pas activée automatiquement pour les gens qui ont déjà
un fichier de config, mais elle est présente pour ceux qui en crée un.

Vincent me les as cassé lors du commit ab2f04c6. En particulier
il a remplacé la variable de destination de --noclipboard en "clipboard"
sans changer la valeur à enregistrer (qui était False). Bref, quand on
tapait "--noclipboard" ça enregistrait False dans la variable "noclipboard" …
L'option --clipboard était devenue du code mort …

Voilà le comportement souhaité :
À moins que l'utilisateur ne précise une option, on essaie de deviner si un
clipboard est dispo et on l'utilise.

Si l'utilisateur utilise une des options, il a raison et on l'écoute sans
se poser de questions. Typiquement, si "--clipboard" est précisé, on n'a
pas à vérifier nous-même que /usr/bin/xclip existe. Par ailleurs, cela
permet de faire marcher le clipboard sur des setups "exotiques", par
exemple s'il n'est pas dans /usr/bin/. Remarquer que l'appel à xclip
se fait en relatif contrairement au test, ce qui permet d'override xclip ou d'en
mettre un autre perso dans son ~/bin/.

Rajout d'un commentaire dans le code, pour éviter qu'on ne ré-efface cette
feature :(

Ce qui faisait planter l'appel à la fonction de restoration.
Celle-ci s'attend à recevoir old_clipboard=None si rien à restorer

300f13b2 introduit une clé 'whoami' dans un dico, et l'efface
de temps en temps à coup de pop. Sauf qu'il s'agit toujours du même
dictionnaire (mémoisation oblige), on règle le problème en
copyant la structure à chaque appel.

On n'a pas envie d'ouvrir une session ssh pour ça.
Bon, le test fait un peu ducktape…

Une liste DONT_NEED_SSH et un décorateur @dont_need_ssh ?

Bugfix sur 300f13b2, on cherchait à virer
le role whoami deux fois de suite.

On n'a plus besoin de la variable de conf 'user' sur le client, le serveur la renvoie dans le rôle whoami.

Du coup, évidemment, il ne faut pas définir un rôle "whoami".
Si le serveur en trouve un, il lèvera une exception.