This is based on some code from (closed) PR #7872, but reworked based on
suggestions by @abadger and the other core team members.
Closes#7872 by @darkk (hash_merge/hash_replace filters)
Closes#11153 by @telbizov (merged_dicts lookup plugin)
Now we issue a "Reading … from stdin" prompt if our input isatty(), as
gpg does. We also suppress the "x successful" confirmation message at
the end if we're part of a pipeline.
(The latter requires that we not close sys.stdout in VaultEditor, and
for symmetry we do the same for sys.stdin, though it doesn't matter in
that case.)
This allows the following invocations:
# Interactive use, like gpg
ansible-vault encrypt --output x
# Non-interactive, for scripting
echo plaintext|ansible-vault encrypt --output x
# Separate input and output files
ansible-vault encrypt input.yml --output output.yml
# Existing usage (in-place encryption) unchanged
ansible-vault encrypt inout.yml
…and the analogous cases for ansible-vault decrypt as well.
In all cases, the input and output files can be '-' to read from stdin
or write to stdout. This permits sensitive data to be encrypted and
decrypted without ever hitting disk.
Note that this test was broken in devel because it was really just
duplicating the AES256 test because setting v.cipher_name to 'AES'
no longer selected AES after it was de-write-whitelisted.
Now that we've removed the VaultAES encryption code, we embed static
output from an earlier version and test that we can decrypt it.
Now that VaultLib always decides to use AES256 to encrypt, we don't need
this broken code any more. We need to be able to decrypt this format for
a while longer, but encryption support can be safely dropped.
added info/link for ansible-lockdown to mailing list section, minor editing
(can't help myself it seems) to the paragraph about subscribing from a non-google account
Now we don't have to recreate VaultEditor objects for each file, and so
on. It also paves the way towards specifying separate input and output
files later.
It's unused and unnecessary; VaultLib can decide for itself what cipher
to use when encrypting. There's no need (and no provision) for the user
to override the cipher via options, so there's no need for code to see
if that has been done either.
'tox -e py26' would fail for me because python -m compileall would crawl
under .tox/py27 and, unsurprisingly, get SyntaxErrors on files from the
Python 2.7 standard library using syntax features not supported by
Python 2.6.
The bit about git rebase vs git merge is repeated in the paragraph below. The bit about test/integration is repeated in the paragraph above.
(And the bit about aliasing git pull to git pull --rebase is unclear, since git's aliases cannot override builtin operations.)
