Git шифровать/дешифровать файлы удаленных репозиториев, в то время как push/pull

Ответ 1

И да и нет.

Вы можете попытаться зависеть от ловушки, но это предполагает, что они установлены в удаленных местах, и это не всегда надежно.

Другим способом достижения почти такого же эффекта было бы использование драйвера фильтра атрибутов smudge/clean, но не для полного репо.

^{(Источник: книга Pro Git: настройка Git - атрибуты Git)}

Таким образом, сценарий smudge может декодировать файлы, в то время как сценарий clean будет кодировать их.
Опять же, это может работать для нескольких конфиденциальных файлов, а не для полного репо.

Конечно, эти сценарии не будут находиться в самом хранилище, и будут управляться/передаваться другим способом.

Как отметил в комментариях Alkaline, эта идея не подходит для репо, как прокомментировал главный сопровождающий Git Джунио С. Хамано в 2009 году:

Поскольку единственным смыслом diff.textconv является разрешение преобразования с потерями (например, msword-to-text), примененного к паре содержимого preimage и postimage (которые должны быть "чистыми"), перед тем как дать текстовый diff для потребление человеком.

Приведенный выше конфиг может работать, но если вы действительно хотите зашифрованное хранилище, вам следует использовать шифрованную файловую систему.
Это даст дополнительное преимущество в том, что рабочее дерево, связанное с вашим хранилищем, также будет зашифровано.

Несмотря на то, что она не масштабируется до полного репо, идея была реализована (спустя 3 года в 2013 году) с помощью git-crypt, как подробно описано в ответе Доминика Черизано.
git-crypt использует драйвер фильтра содержимого (реализован в cpp, где commands.cpp настраивает ваши .gitattributes с соответствующими командами smudge и clean filter).
Как и любой драйвер фильтра содержимого, вы можете ограничить применение git-crypt набором файлов, которые вы хотите, в том же файле .gitattributes:

secretfile filter=git-crypt diff=git-crypt
*.key filter=git-crypt diff=git-crypt

Как уже упоминалось в README:

git-crypt использует фильтры git, которые не были разработаны с учетом шифрования.

Таким образом, git-crypt - не лучший инструмент для шифрования большинства или всех файлов в хранилище.
Где действительно хорошо работает git-crypt это то, где большая часть вашего репозитория общедоступна, но у вас есть несколько файлов (возможно, закрытых ключей с именем *.key или файл с учетными данными API), которые необходимо зашифровать.

Для шифрования всего хранилища рассмотрите возможность использования системы типа git-remote-gcrypt.

(см. больше в spwhitton/tech/code/git-remote-gcrypt, от Шона Уиттона)

Ответ 2

Вы можете посмотреть этот проект: https://github.com/shadowhand/git-encrypt

ОБНОВЛЕНИЕ. Этот вышеописанный проект устарел и рекомендует использовать https://github.com/AGWA/git-crypt

Ответ 3

Как защитить публичные и частные удаленные активы с помощью git-crypt.

• Прозрачный для всех клиентов и сервисов git (например, GitHub, BitBucket и т.д.).
• Поддержка Linux, OSX и Windows.
• Шифрование на уровне активов (см . Ответ VonC).
• Шифр AES-256.
  
  

Создайте свой 256-битный закрытый ключ (СОХРАНИТЕ И ЗАЩИТИТЕ ЭТОТ КЛЮЧ)

sudo apt install git-crypt 
mkdir key; cd key;
git init; git-crypt init
git-crypt export-key ~/crypt.key

Вставьте файл с именем .gitattributes в каждый корневой каталог репо.
Он должен содержать один шаблон ресурса на файл, каталог или тип, который вы хотите зашифровать:

docs/doc.txt  filter=git-crypt diff=git-crypt
js/**         filter=git-crypt diff=git-crypt
*.java        filter=git-crypt diff=git-crypt
src/cpp/*.h   filter=git-crypt diff=git-crypt

Шифровать активы в каждом репо:

cd repo-root-directory
git-crypt unlock ~/crypt.key
git-crypt status -f
Push (from command line or git client)

Продолжайте работать как обычно.

• Запустите git-crypt unlock ~/crypt.key один раз для любых новых клонов этих защищенных репозиториев.
• Вы можете удалить старые незашифрованные истории коммитов на всех ветках и тегах.
• Если вы используете git-клиент, он должен полностью поддерживать git-фильтры и diff файлы.
  
  
  

Ответ 4

Есть два способа сделать это.

Один из них - использовать проект типа git -crypt, http://www.agwa.name/projects/git-crypt/ который добавляет в подгонки, чтобы тянуть и толкать процесс, или настроить фильтры вручную, как описано здесь https://gist.github.com/shadowhand/873637

Другим способом, если вы работаете в среде linux, является использование ecryptfs. Для этого сценария в базе вашего каталога проекта вы могли бы, например, создать два каталога

project/encrypted_src

project/src

Затем из корня каталога проекта вы будете монтироваться с помощью команды

sudo mount -t ecryptfs encrypted_src src

ввод пароля и принятие значений по умолчанию при появлении запроса. На этом этапе файлы, помещенные в src/, будут зашифрованы в encrypted_src/ "на лету". Когда вы закончите просто

sudo umount src

и остаются только зашифрованные файлы. По сути файлы фиксируются и вытесняются из encrypted_src/и редактируются в src. До тех пор, пока все используют одну и ту же pass-фразу (или монтируется с одним и тем же ключом), репо может совместно использоваться разработчиками. Также вы можете полюбить. Вы можете зашифровать имена файлов, а также просто содержимое файла или зашифровать разные папки в репо с помощью разных паролей или ключей. Последняя функция хороша, если у вас есть файлы конфигурации с конфиденциальной информацией о доступе, которые отдельные группы (dev, test, production) захотят поддерживать конфиденциально.

Тем не менее, имейте в виду, что как только вы начинаете шифровать материал. Вы теряете много преимуществ управления версиями, например, возможность видеть различия между различными коммитами. Если у вас есть проект любого размера, возможность совершения совершения совершения будет неоценима. Если вы ожидаете ошибок, в какой-то момент, способность анализировать и находить свою точку входа путем отслеживания назад через историю фиксации также будет бесценной. Поэтому сначала закрепите свой сервер, а затем используйте шифрование только там, где имеет смысл защищать конфиденциальную информацию в контроле источника. Только мои 2 цента.

Ответ 5

Есть крючки Tahoe-LAFS, предоставленные git-annex, что, по общему признанию, может быть сложнее, чем вам нужно.