Comments 26
А как будут выглядеть чейнджсеты? То есть получается как бы работа с бинарными файлами?
Проверил штатный git diff,
к сожалению да, как двоичные файлы, но, возможно, это можно обойти дополнительными фильтрами.
В крайнем случае, можно получить копии открытых (расшифрованных) версий файлов и сравнить их в индивидуальном порядке.
Смысл метода скрыть не всё, а только что-то ну очень секретное.
к сожалению да, как двоичные файлы, но, возможно, это можно обойти дополнительными фильтрами.
В крайнем случае, можно получить копии открытых (расшифрованных) версий файлов и сравнить их в индивидуальном порядке.
Смысл метода скрыть не всё, а только что-то ну очень секретное.
stackoverflow.com/questions/1557183/is-it-possible-to-include-a-file-in-your-gitconfig
[filter «gpg»]
smudge = gpg -d -q --batch --no-tty
clean = gpg -ea -q --batch --no-tty -r C920A124
[diff «gpg»]
textconv = decrypt
[filter «gpg»]
smudge = gpg -d -q --batch --no-tty
clean = gpg -ea -q --batch --no-tty -r C920A124
[diff «gpg»]
textconv = decrypt
А не проще TrueCrypt поставить и организовать хранилище на шифрованном разделе?
Да, это подойдёт для сокрытия всего. Но тогда хранилище уже не будет на сервере представлено в виде Bare-репозитория (тогда в этом уже нет смысла).
Смысл скрыть именно несколько файлов и при этом оставить штатный доступ к Git.
Если образ диска разместить на сервере — то сколько человек сможет с ним работать одновременно?
Лично я использовал FUSE + SSHFS и монтировал AES-тома через SSH. Но пока диск у меня, остальные не могут с ним работать безопасно — это плохо кончится. TrueCrypt свободен от этой проблемы?
Смысл скрыть именно несколько файлов и при этом оставить штатный доступ к Git.
Если образ диска разместить на сервере — то сколько человек сможет с ним работать одновременно?
Лично я использовал FUSE + SSHFS и монтировал AES-тома через SSH. Но пока диск у меня, остальные не могут с ним работать безопасно — это плохо кончится. TrueCrypt свободен от этой проблемы?
Если образ диска разместить на сервере, монтировать его и расположить на нем GIT репозитарий, то работа с GIT для всех будет выглядеть абсолютно прозрачно пока диск не размонтируют. Или, может быть, я вас неправильно понял? Может быть, смысл в том, чтобы никто не смог работать с некоторыми конкретными файлами в репозитарии?
Вопрос в том, где этот диск будет смонтирован (возможности TrueCrypt). Допустим, 100 разных человек в разных точках земли, смогут ли смонтировать этот диск и работать с репозиторием, так чтобы целостность данных была в порядке?
Ограничения этого метода:
1. Если внутри одной организации — то можно конечно расшарить один смонтированный диск между сотрудниками.
2. На GitHub такое не пройдёт
3. Возможна физическая порча репозитория (он уже не сокрыт за сервером, а вот он как локальный)
Ограничения этого метода:
1. Если внутри одной организации — то можно конечно расшарить один смонтированный диск между сотрудниками.
2. На GitHub такое не пройдёт
3. Возможна физическая порча репозитория (он уже не сокрыт за сервером, а вот он как локальный)
к сожалению, тогда владельцам хостинга теоретически станут доступны файлы на зашифрованном разделе, пока он смонтирован (т.е. они могут, по крайней мере легко, запустить соответствующий софт на сервере).
Для предотвращения доступа владельцев сервера к вашим данным есть только два основных направления — усложнение доступа (нестандартные схемы, постоянный контроль софта и т.д.) и дешифровка на клиенте (причем возможен вариант, когда один из надежных клиентов становится временным сервером, а хостинг провайдера используется как простое хранилище). В статье описан второй вариант — в данном случае это наиболее простой и эффективный метод, жаль что ограничивает функционал на стороне клиента. Но первый вариант — не на столько надежен, как второй.
p.s.
Для предотвращения доступа владельцев сервера к вашим данным есть только два основных направления — усложнение доступа (нестандартные схемы, постоянный контроль софта и т.д.) и дешифровка на клиенте (причем возможен вариант, когда один из надежных клиентов становится временным сервером, а хостинг провайдера используется как простое хранилище). В статье описан второй вариант — в данном случае это наиболее простой и эффективный метод, жаль что ограничивает функционал на стороне клиента. Но первый вариант — не на столько надежен, как второй.
p.s.
p.s. а если клонировать репозитарий уже от клиента, но без шифрования фильтрами, файлы будут переданы дешифрованными или зашифрованными?
Зачем скрипты на перле, если бы одна строка «openssl ...» сработала бы?
Может быть. Процесс эксперимента с фильтрами не сразу привёл к результату. Мне удобнее писать Perl-скрипты, вместо SH-скриптов, поэтому получилось именно так.
На больших файлах print `command`; даст не лучшую производительность, так как будет буферизировать всё в памяти. А запись «секретных» данных лишний раз во временный файл в /tmp вообще противопоказана.
По поводу /tmp — предполагается, что это Ваша машина (клиент).
Иначе и редактировать файлы на ней не стоит.
Иначе и редактировать файлы на ней не стоит.
Вы же за машиной не один работаете.
Если уж секретный, то в home пишите, а то из tmp его быстро уведут.
Если уж секретный, то в home пишите, а то из tmp его быстро уведут.
К счастью, в конкретный текущий момент времени один. Сразу после использования файл удаляется. Но использование tmp в home поддерживаю всё равно.
И как тут уже отмечалось, Perl скрипты остались от иследования фильтров.
Можно, действительно, обойтись openssl в одну строку без обёртки и без временных файлов.
И как тут уже отмечалось, Perl скрипты остались от иследования фильтров.
Можно, действительно, обойтись openssl в одну строку без обёртки и без временных файлов.
Доверие доверием, а подстраховаться никогда не повредит.
Дополнительное шифрование — это второй уровень защиты.
К примеру, Вы платите за хостинг и размещаете там репозиторий.
Насколько Вы доверяете хостеру и местным специалистам, который день и ночь шныряют по SSH?
Это как замки в квартире — Вы можете их и вовсе не ставить, но тогда…
А когда Вы их ставите, разве Вы живёте не в скомпроментированном мире?
Дополнительное шифрование — это второй уровень защиты.
К примеру, Вы платите за хостинг и размещаете там репозиторий.
Насколько Вы доверяете хостеру и местным специалистам, который день и ночь шныряют по SSH?
Это как замки в квартире — Вы можете их и вовсе не ставить, но тогда…
А когда Вы их ставите, разве Вы живёте не в скомпроментированном мире?
Если есть доступ по SSH и Гит на сервере установлен, то никаких проблем возникнуть не должно.
Без рутовых прав нельзя.
теоретически, при наличии ssh и установленных зависимостей (некоторые можно самому поставить) можно попытаться установить все необходимое в домашнюю директорию, очень даже может быть что что-нибудь потребуется пересобрать с опцией --preffix=/home/username/ но что то мне говорит что геморою будет намного больше чем стоит любая самая вшивая vps.
На самом деле можно.
Только не нужно ставить в директории не принадлежащие Вашему пользователю (например, в /usr, /usr/local).
Просто переопределите prefix при configure.
Только не нужно ставить в директории не принадлежащие Вашему пользователю (например, в /usr, /usr/local).
Просто переопределите prefix при configure.
Не скажу по поводу «заморачиваться», но лично я за практику — попробовать стоит по любому.
Из моего опыта — удачно удалось развернуть Git на 301-м тарифе РуЦентра — там в SSH даже gcc есть — сначала собрал nginx, потом git, svn там из коробки идёт.
Из моего опыта — удачно удалось развернуть Git на 301-м тарифе РуЦентра — там в SSH даже gcc есть — сначала собрал nginx, потом git, svn там из коробки идёт.
Итак, резюмирую укороченное решение шифрования-дешифрования с возможностью производить diff:
Вместо Perl-скриптов и для работы diff в определении фильтра прописываем:
Для нужных файлов в .gitattributes:
При модификации .gitattributes на стороне клиента после клонирования, достаточно выполнить git stash для применения новых настроек фильтра smudge. Чтобы не было недоразумений, не забудьте добавить .gitattributes в хранилище.
Вместо Perl-скриптов и для работы diff в определении фильтра прописываем:
[filter "private"]
clean = openssl enc -rc5 -k SecurePassword -nosalt
smudge = openssl enc -d -rc5 -k SecurePassword -nosalt
[diff "private"]
textconv = cat
Для нужных файлов в .gitattributes:
*.h filter=private diff=private
При модификации .gitattributes на стороне клиента после клонирования, достаточно выполнить git stash для применения новых настроек фильтра smudge. Чтобы не было недоразумений, не забудьте добавить .gitattributes в хранилище.
Sign up to leave a comment.
Шифрование важных файлов в Git