git шифрует / дешифрует файлы удаленного репозитория во время push / pull

Question

Можно ли автоматически шифровать файлы с помощью git push перед передачей в удаленный репозиторий?И автоматически декодировать их во время 'git pull'.

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

Answer 1

Да и нет.

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

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

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

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

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

Поскольку Alkaline указывает на в комментариях , эта идея не масштабируется для репо, поскольку главный сопровождающий git Junio ​​C. Hamano комментирует еще в 2009 :

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

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

---

Несмотря на то, что она не масштабируется до полного репо, идея была реализована (спустя 3 года в 2013 году) с git-crypt, как подробно описано в Доминик Черизано ответ .
git-crypt использует драйвер фильтра содержимого (реализован в cpp, с commands.cpp, настраивающим .gitattributes с соответствующими командами фильтра smudge и clean).
Как и любой драйвер фильтра содержимого, вы можете ограничить применение 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 , от Шон Уиттон )

Answer 2

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

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

Answer 3

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

• Прозрачный для всех клиентов и сервисов git (например, GitHub, BitBucket, и т.д.).
• Поддержка Linux, OSX и Windows.
• Уровень активов шифрование (см. VonC's ответить ).
• 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 как обычно.

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

Answer 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. Пока все используют одну и ту же парольную фразу (или монтирует с одним и тем же ключом), репо может быть распространено среди разработчиков. Также вы можете полюбоваться. Вы можете зашифровать имена файлов, а также только их содержимое, или зашифровать разные папки в репозитории, используя разные парольные фразы или ключи. Последняя функция удобна, если у вас есть файлы конфигурации с конфиденциальной информацией о доступе, которую отдельные группы (dev, test, production) захотят поддерживать в частном порядке.

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

Answer 5

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