Почистіть чи очистіть фільтри для розкриття секретів


20

Я намагаюся налаштувати фільтр очищення / розмазання в git, щоб мати автоматичне шифрування та розшифрування файлів, що містять секрети через команду ansible-vault .

Своєрідність команди ansible-treult полягає в тому, що вона не є ідентичною (вона створює різний двійковий файл кожного разу, коли вона викликається одними і тими ж даними).

Я почав із реалізації, запропонованої на цій сторінці блогу . На жаль, це не працює належним чином, як і колись викликається розмазування (будь то git checkout, або просто git status), секретні файли виглядають як змінені для git, навіть якщо це не так.

Тож я задумався, чи може git порівнювати бінарний файл, який він має в індексі, з чистим відфільтрованим поточним файлом, і я намагався розробити цей сценарій, як слід:

#!/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

Різниця тут полягає в тому, що він намагається порівняти поточну та HEAD версії простого текстового (незашифрованого) секретних файлів, і лише у випадку, якщо вони відрізняються, виводиться новий бінарний блок, зашифрований з ansible-treult.

На жаль, після цієї зміни git продовжує думати, що секретний файл завжди змінюється. Навіть після git addповторного користування файлом, щоб обчислити gb blob, git вважає, що файл інший, і нехай зміна переходить у фіксацію. Зауважте, що git diffповерніть порожні зміни, як слід.

Для довідки, це пляма:

#!/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

і це відрізняється:

#!/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

Я оновив сценарії, які ведуть себе правильно, за винятком випадків, коли git намагається автоматизувати конфлікти на сховищах, які я опублікую незабаром
ᴳᵁᴵᴰᴼ

1
Кидання пляшки в море, але: чи файл може бути різним через різні закінчення рядків або різні кодові сторінки?
Тенсібай

Я б спробував зняти -nпігментне відлуння, але це здогад. Немає прихованого варіанту для git diff, який дозволяє йому ігнорувати закінчення в одному рядку?
Тенсібай

Ще одна ідея: github.com/dellis23/ansible-toolkit (я заглиблюся в цей день глибше)
Тенсібай

Відповіді:


8

Проблема тут викликана випадковою сіллю в шифруванні ансибіл-склепіння. Ви можете зламати клас VaultEditor, щоб передати йому сіль з аргументу в ansible-vault. На lib/ansible/parsing/vault/__init__.pyцьому рядку генерується випадкова сіль . Він викликається з lib / ansible / cli / vault.py, де ви можете легко додати аргумент за фіксовану сіль. Якщо ви все-таки зміните, надішліть, будь ласка, виправлення на тему "Ansible", я б хотів його використовувати.

Ця проблема далі обговорюється тут у новинах хакерів . Є й інші реалізації з допомогою інструментів , які приймають основні сіль, а саме gitcrypt , transcrypt . Ось також посилання на ще одну реалізацію з використанням ansible-vault, що називається ansible-vault-tools , але ця проблема має солі, наскільки я знаю.


Якщо ви перевіряєте код, я використовую контрольну суму для вирішення проблеми змінної солі, тобто. спершу розшифруйте сховище HEAD у папці tmp та порівняйте контрольні суми простих текстових файлів, перш ніж створювати нову двійкову крапку. Це трохи повільно, але насправді нормально. Моя проблема зараз в злитті; в певних ситуаціях це працює, в інших я отримую автоматичний відрив, перш ніж я зможу його розшифрувати, і він зламається.
ᴳᵁᴵᴰᴼ

Якщо ви подивитесь на три приклади, які я зв'язав, є також деякі обхідні питання щодо злиття. І це також обговорюється в коментарях новин хакера.
Jiri Klouda

Злиття BTW є складним. Що вам потрібно усвідомити, це те, що у випадку, коли під час злиття ви виберете всі свої зміни або всі зміни з висхідного потоку, git визначить це за допомогою хеш-порівняння, яке б спрацювало, якби сіль була правильною. Температурного файлу недостатньо для очищення / змазування. Вам потрібно буде зробити те ж саме під час злиття, а в разі безконфліктного злиття перевірити правильну вже зашифровану версію від git та використати її на відміну від повторного шифрування новою випадковою сіллю.
Jiri Klouda

Не впевнений, я розумію, що ви тут говорите; злиття відбудеться в простому тексті сховищ (як це відбувається через різний), і маючи секрети завжди позначатись як конфлікт навіть для автоматичного злиття, таким чином, включаючи об'єднані повторно зашифровані секрети в межах будь-якого злиття, не буде дійсно представляють проблему (для мене).
ᴳᵁᴵᴰᴼ

Чи можете ви потім бути конкретними щодо питань злиття? Вам слід надати відтворюваний кейс. Але я б все-таки запропонував шукати ідеї в 3-х проектах, згаданих вище. Що стосується проблем з об'єднанням, коли ви об'єднуєте вміст A із вмістом B, і ви вирішили приймати завжди A або завжди B, для систем управління версіями, що є особливим випадком, і вони іноді це робитимуть, пов'язуючи версію разом. Git робить це через хеш для вмісту, тому він припустить, що хеш буде однаковим, але якщо ви повторно шифруєте, навіть якщо вміст є всім A, хеш не буде однаковим. Але у вас може виникнути інше питання
Ірі Клоуда,
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.