ansible/ansible — pull request #6628 by ptone (2014-03-22 05:37:41+00:00)
Title: Add support for Python multiplatform keyring library to Ansible Vault

This will use the keyring module if it is installed, and otherwise revert to the default behavior

A few points to note, or change:

keyring supports two pieces of information to key a password - a service name, and an account/username

For now, this is written to store a single universal PW for all vault use. ("Ansible", "default-vault")

The second piece of information could be used a number of ways:

* It could be used to store a file path - and store a different password per file - but this would break if the file is moved
* It could be used with a project "label" that can be easily remembered, without requiring the password to be weak

The next issue is that users may **Expect** to be prompted for a password for encrypted content, and find it disconcerting if the editor just opens. I've added a message to this effect - but one would not see it in the shell until the editor closes - an arbitrary delay could be added if that was a concern.

I've added a prompt for people to confirm they want to store the PW in the keyring - the term keyring is the platform agnostic term, which may throw off OS X users who are only familiar with "keychain".

Since there is one, and only one vault-password in this implementation, it will ask you to confirm you want to replace it, as this may be used by other vaults.

A broken part of this current implementation currently is the behavior encountered when a vault password is stored in the keyring, but it does not match the PW that was used to encrypt a file.

I see two possible solutions to this situation:

Be optimistic and try the keyring PW if it exists, and if there is a decryption error - prompt for a password. This would involve adding some sort of force_prompt kwarg to the ask_vault_passwords function.

Another option is to just put all of this under an explicit --keyring or --use-keyring arg to ansible-vault tool

That would be just slightly less convenient, but more explicit overall and force all the intent to be made clear up front. Happy to rework in that direction.