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.
Зачем скрипты на перле, если бы одна строка «openssl ...» сработала бы?
Может быть. Процесс эксперимента с фильтрами не сразу привёл к результату. Мне удобнее писать Perl-скрипты, вместо SH-скриптов, поэтому получилось именно так.
На больших файлах print `command`; даст не лучшую производительность, так как будет буферизировать всё в памяти. А запись «секретных» данных лишний раз во временный файл в /tmp вообще противопоказана.
По поводу /tmp — предполагается, что это Ваша машина (клиент).
Иначе и редактировать файлы на ней не стоит.
Иначе и редактировать файлы на ней не стоит.
Вы же за машиной не один работаете.
Если уж секретный, то в home пишите, а то из tmp его быстро уведут.
Если уж секретный, то в home пишите, а то из tmp его быстро уведут.
К счастью, в конкретный текущий момент времени один. Сразу после использования файл удаляется. Но использование tmp в home поддерживаю всё равно.
И как тут уже отмечалось, Perl скрипты остались от иследования фильтров.
Можно, действительно, обойтись openssl в одну строку без обёртки и без временных файлов.
И как тут уже отмечалось, Perl скрипты остались от иследования фильтров.
Можно, действительно, обойтись openssl в одну строку без обёртки и без временных файлов.
UFO just landed and posted this here
Доверие доверием, а подстраховаться никогда не повредит.
Дополнительное шифрование — это второй уровень защиты.
К примеру, Вы платите за хостинг и размещаете там репозиторий.
Насколько Вы доверяете хостеру и местным специалистам, который день и ночь шныряют по SSH?
Это как замки в квартире — Вы можете их и вовсе не ставить, но тогда…
А когда Вы их ставите, разве Вы живёте не в скомпроментированном мире?
Дополнительное шифрование — это второй уровень защиты.
К примеру, Вы платите за хостинг и размещаете там репозиторий.
Насколько Вы доверяете хостеру и местным специалистам, который день и ночь шныряют по SSH?
Это как замки в квартире — Вы можете их и вовсе не ставить, но тогда…
А когда Вы их ставите, разве Вы живёте не в скомпроментированном мире?
UFO just landed and posted this here
Если есть доступ по SSH и Гит на сервере установлен, то никаких проблем возникнуть не должно.
UFO just landed and posted this here
Без рутовых прав нельзя.
теоретически, при наличии 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