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

Question

Я ищу зашифрованную систему контроля версий. В основном я хотел бы

• Зашифруйте все файлы локально перед отправкой на сервер. Сервер никогда не должен получать файлы или данные в незашифрованном виде.

• Каждая другая функция должна работать почти так же, как сегодня SVN или CVS.

Кто-нибудь может порекомендовать что-то подобное? Я провел много поисков, но ничего не могу найти.

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

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

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

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

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

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

Answer 5

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

Answer 6

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

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

Answer 7

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

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

Answer 8

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

Answer 9

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

Answer 10

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

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

Это можно сделать с помощью простого сценария оболочки, более удобного.

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

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

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