20

I am trying to setup clean/smudge filter in git to have automatic encrypting and decrypting of files containing secrets thru ansible-vault command.

Peculiarity of the ansible-vault command is that it is not idempotent (it creates a different binary each time it is invoked on the same data).

I started with the implementation suggested in this blog page. Unfortunately it did not work correctly, as whenever smudge is called (be it a git checkout , or just git status), the secret files looks as modified for git, even if it is not.

So I wondered if git would be comparing the binary he has in the index with the clean filtered current file, and I tried to build on those script like follows:

#!/bin/sh -x
# clean filter, it is invoked with %f

if [ ! -r "$HOME/.vault_password" ]; then
  exit 1
fi

tmp=`mktemp`
cat > $tmp

# get the plain text from the binary in the index
tmphead=`mktemp`
git show HEAD:$1 > $tmphead
contenthead=`echo "embedded" | ansible-vault view $tmphead --vault-password-file=$HOME/.vault_password`
export PAGER=cat
echo -n "$contenthead" | tee $tmphead

# if current and index plain text version differ
if [ "`md5sum $tmp | cut -d' ' -f1`" != "`md5sum $tmphead | cut -d' ' -f1`" ]; then
  tmpcrypt=`mktemp`
  cp $tmp $tmpcrypt
  # generate a new crypted blob
  echo "embedded" | ansible-vault encrypt $tmpcrypt --vault-password-file=$HOME/.vault_password > /dev/null 2>&1
  cat "$tmpcrypt"
else
  # just return the HEAD version
  cat "$tmphead"
fi

rm $tmp $tmphead $tmpcrypt

The difference here is that it tries to compare the current and HEAD versions of the plain text (unencrypted) secret files, and only in case they differ output a new binary blob encrypted with ansible-vault.

Unfortunately, after this change git continues to think the secret file is always modified. Even after git adding the file again, so that the git blob is computed, git thinks the file is different and let the change go into the commit. Note that git diff return empty changes, as it should.

For reference, this is smudge:

#!/bin/sh

if [ ! -r "$HOME/.vault_password" ]; then
  exit 1
fi

tmp=`mktemp`
cat > $tmp

export PAGER='cat'
CONTENT="`echo "embedded" | ansible-vault view "$tmp" --vault-password-file=$HOME/.vault_password 2> /dev/null`"

if echo "$CONTENT" | grep 'ERROR: data is not encrypted' > /dev/null; then
  echo "Looks like one file was commited clear text"
  echo "Please fix this before continuing !"
  exit 1
else
  echo -n "$CONTENT"
fi

rm $tmp

and this is diff:

#!/bin/sh

if [ ! -r "$HOME/.vault_password" ]; then
  exit 1
fi

export PAGER='cat'
CONTENT=`echo "embedded" | ansible-vault view "$1" --vault-password-file=$HOME/.vault_password 2> /dev/null`

if echo "$CONTENT" | grep 'ERROR: data is not encrypted' > /dev/null; then
  cat "$1"
else
  echo "$CONTENT"
fi
  • I have updated scripts which behave correctly except when git tries to automerge conflicts on vaults which I'll post shortly – ᴳᵁᴵᴰᴼ Mar 1 '17 at 10:30
  • 1
    Throwing a bottle at the sea but: could the file be different because of different line endings or different code page ? – Tensibai Mar 1 '17 at 13:41
  • I'd try removing the -n from the smudge echo, but that's a guess. No hidden option for git diff telling it to ignore single line endings ? – Tensibai Mar 1 '17 at 13:50
  • Yet another idea: github.com/dellis23/ansible-toolkit (I will dig more deeply into this one day) – Tensibai Mar 10 '17 at 9:24
8

The problem here is caused by the random salt in ansible-vault encryption. You can hack VaultEditor class to pass the salt to it from an argument in ansible-vault. The random salt is generated in lib/ansible/parsing/vault/__init__.py on this line. It is called from lib/ansible/cli/vault.py where you can easily add the argument for fixed salt. If you do change it, please submit an upstream patch to Ansible, I'd love to use it.

This problem is further discussed here on hacker news. And there are other implementations with tools that take fixed salt, namely gitcrypt, transcrypt. Here is also a link to one more implementation using ansible-vault called ansible-vault-tools, but this one has the same salt issue as far as I know.

  • If you check the code, I am using a checksum to workaround the variable salt issue, ie. decrypt the HEAD vault in a tmp folder first and compare the checksums of plain text files before generating the new binary blob. That's a bit slow but actually ok. My problem is on merges now; in certain situations it works, in others I get the blob automerged before i can decrypt it and it breaks. – ᴳᵁᴵᴰᴼ Mar 14 '17 at 8:29
  • If you look into the three examples I have linked, there are some workarounds on the merges as well. And it is being discussed in the hacker news comments too. – Jiri Klouda Mar 14 '17 at 13:53
  • BTW Merging is tricky. What you need to realize is that in case where you pick all your changes or all changes from upstream during the merge, git would figure that out through hash comparison, which would work if the salt was right. The temp file is not enough on clean/smudge. You would need to do the same on merge and in case of non-conflict merge checkout the correct already encrypted version from git and use that one as opposed to re-encrypting with new random salt. – Jiri Klouda Mar 14 '17 at 13:58
  • Not sure i understand what you are saying here; merging would happen on the plain text of vaults (as it goes thru diff-ing), and having the secrets always be marked as a conflict even for auto-merges, thus including a merged re-encrypted secrets within any merge commit, would not really represent a problem (for me). – ᴳᵁᴵᴰᴼ Mar 14 '17 at 16:51
  • Can you be then specific on the merge issues? You should provide reproducible case. But I would still suggest to look for ideas into the 3 projects mentioned above. As for the merging issues, when you merge content A with content B and you have all resolved to take always A or always B, for version control systems that is a special case and they will sometimes do that by linking the version together. Git does it through hash on the content, so it will assume the hash will be the same, but if you re-encrypt, even if content is all A, the hash will not be the same. But you could have other issue – Jiri Klouda Mar 14 '17 at 18:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.