Есть ли зашифрованная система контроля версий?

Ответ 1

Вместо этого вы должны зашифровать канал данных (ssl/ssh) и обеспечить доступ к серверу. Шифрование данных заставит SVN существенно рассматривать все как двоичный файл. Он не может выполнять никаких различий, поэтому он не может хранить дельта. Это побеждает цель дельта-подхода.
Ваш репозиторий станет огромным, очень быстрым. Если вы загрузите файл размером 100 кбайт, а затем снова измените 1 байт и проверите, сделайте это еще 8 раз (всего 10 оборотов), в хранилище будет храниться 10 * 100 кб, а не 100 кб + 9 маленьких дельт (пусть назовите его 101 кб).

Обновление: @TheRook объясняет, что можно делать дельта с зашифрованным репозиторием. Таким образом, это возможно. Тем не менее, мой первоначальный совет стоит: это не стоит хлопот, и вам лучше с шифрованием ssl/ssh и обеспечением безопасности сервера. то есть "лучшие практики".

Ответ 2

Можно создать систему управления версиями шифрованного текста. Было бы идеальным использовать потоковый шифр, такой как RC4-drop1024 или AES-OFB. Пока один и тот же ключ + iv используется для каждой ревизии. Это будет означать, что один и тот же поток PRNG будет генерироваться каждый раз, а затем XOR'ed с кодом. Если какой-либо отдельный байт отличается от другого, тогда у вас есть несоответствие, а текст шифрования его сам будет объединен нормально.

Также может быть использован блочный шифр в режиме ЕЦБ, где наименьшее несоответствие будет иметь размер 1 блок, поэтому было бы идеально использовать небольшие блоки. С другой стороны, режим CBC может создавать широко различный шифрованный текст для каждой ревизии и, следовательно, нежелателен.

Я понимаю, что это не очень безопасно, режимы OFB и ECB обычно не используются, поскольку они слабее, чем режим CBC. Жертва IV также нежелательна. Более того, неясно, с чем защищается атака. Там, где использование чего-то типа SVN + HTTPS очень распространено и также безопасно. Мой пост просто говорит, что это можно сделать эффективно.

Ответ 3

Почему бы не настроить ваше репо (subversion, mercurial, whatever) на зашифрованную файловую систему и использовать ssh только для подключения?

Ответ 4

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

Используйте вашу любимую систему управления версиями (или любую другую систему управления версиями - svn, git, mercurial, что угодно) для синхронизации между вашим зашифрованным каталогом и удаленным хостом.

Реализация rsyncrypto, которую вы можете скачать сейчас, из Sourceforge не только обрабатывает изменения в байтах, но также вставляет и удаляет. Он реализует подход, очень похожий на подход, который упоминается в "The Rook".

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

Крис Торнтон указывает, что ssh - одно хорошее решение; rsyncrypto - это совсем другое решение. Компромисс:

• Использование rsyncrypto требует переноса нескольких K для каждого "тривиального" изменения, а не полу-a-K, которое он использовал бы с помощью ssh (или в незашифрованной системе). Таким образом, ssh немного быстрее и требует немного меньше хранилища "diff", чем rsyncrypto.
• Использование ssh и стандартного VCS требует, чтобы сервер (хотя бы временно) имел ключи и расшифровывал файлы. С rsyncrypto все ключи шифрования никогда не покидают локальный компьютер. Поэтому rsyncrypto немного более безопасен.

Ответ 5

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

Изменить: здесь расширение прототипа для использования Tahoe-LAFS в качестве внутреннего хранилища для Mercurial.

Ответ 6

SVN имеет встроенную поддержку для безопасной передачи данных. Если вы используете svnserve, вы можете безопасно получить доступ к нему с помощью ssh. Кроме того, вы можете получить доступ к нему через сервер apache с помощью https. Это подробно описано в документации svn.

Ответ 7

Что конкретно вы пытаетесь защитить?

Используйте Subversion ssh или https для доступа репо. Используйте зашифрованную файловую систему на клиентах.

Ответ 8

Посмотрите GIT. Он поддерживает различные крючки, которые могут выполнять работу. См. git шифрование/дешифрование файлов удаленных репозиториев, в то время как push/pull.

Ответ 9

Думали ли вы об использовании Duplicity? Это похоже на rdiff-backup (дельта-резервное копирование), но зашифровано? На самом деле не контроль версий, но, возможно, вам нужен все классный материал, но вы не хотите работать с кем-либо еще. Или просто нажмите/вытащите из локального архива Truecrypt и rsync его в удаленное местоположение. rsync.net имеет приятное описание обоих - http://www.rsync.net/resources/howto/duplicity.html http://www.rsync.net/products/encrypted.html - очевидно, контейнеры Truecrypt по-прежнему хорошо работают.

Ответ 10

Вариант A

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

Например, с помощью mercurial вы можете использовать внутренний веб-сервер и подключать клиентов через VPN. Или вы можете связывать наборы изменений и распространять их с зашифрованными письмами.

Вариант B

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

• возможная потеря данных, когда два разных клиента пытаются получить доступ к VCS одновременно
• сама ссылка должна быть защищена от мошеннического доступа к записи (когда раздел разделяется через NFS, он, скорее всего, закончит конфигурацию, где любой может писать в общий раздел, поэтому даже когда нет возможности читать другие содержание, есть легко отверстие для уничтожения контента)

Могут быть и другие проблемы с вариантом B, поэтому забудьте вариант B.

Вариант C

Как и @Commodore Jaeger, используйте VCS поверх сетевой файловой системы с поддержкой шифрования, например AFS.

Ответ 11

Как и в некоторых комментариях выше, полезным решением может быть шифровать и локально хранить весь репозиторий и синхронизировать его с удаленным ящиком. Например. при использовании git весь репозиторий хранится в директории '.git' в директории проекта.

• zip/encrypt весь проект dir
• загрузите его на сервер (не уверены, что достаточно одного только обработать .git)
• Прежде чем продолжить работу над проектом, загрузите этот архив.
• дешифровать/распаковать и синхронизировать с git (локально)

Это можно сделать с простой оболочкой script более комфортной.

pro: Вы можете использовать любое шифрование, а также каждый VCS, который поддерживает локальные репозитории.

минус отсутствует, очевидно, некоторые функции VCS, когда несколько человек хотят загрузить свою базу кода (ситуация слияния) - хотя, возможно, это можно было бы устранить, избегая перезаписывания удаленно и слияния локально (что вводит замок, здесь начинается кошмар)

Тем не менее, это решение является взломом, а не правильным решением.

Ответ 12

Безопасный источник хранит данные в зашифрованных файлах. Подожди, я заберу это. Они запутаны. И нет никакой другой безопасности, кроме входной двери для обфускации.

Давай, помидор.

Ответ 13

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