Я ищу систему управления зашифрованной версией. В основном я хотел бы
Перед отправкой на сервер все файлы зашифрованы локально. Сервер никогда не должен получать файлы или данные, не зашифрованные.
Каждая другая функция должна работать практически так же, как сегодня SVN или CVS.
Может кто-нибудь порекомендовать что-то подобное? Я сделал много поисков, но я не могу найти что-либо.
Вместо этого вы должны зашифровать канал данных (ssl/ssh) и обеспечить доступ к серверу. Шифрование данных заставит SVN существенно рассматривать все как двоичный файл. Он не может выполнять никаких различий, поэтому он не может хранить дельта. Это побеждает цель дельта-подхода.
Ваш репозиторий станет огромным, очень быстрым. Если вы загрузите файл размером 100 кбайт, а затем снова измените 1 байт и проверите, сделайте это еще 8 раз (всего 10 оборотов), в хранилище будет храниться 10 * 100 кб, а не 100 кб + 9 маленьких дельт (пусть назовите его 101 кб).
Обновление: @TheRook объясняет, что можно делать дельта с зашифрованным репозиторием. Таким образом, это возможно. Тем не менее, мой первоначальный совет стоит: это не стоит хлопот, и вам лучше с шифрованием ssl/ssh и обеспечением безопасности сервера. то есть "лучшие практики".
Можно создать систему управления версиями шифрованного текста. Было бы идеальным использовать потоковый шифр, такой как RC4-drop1024 или AES-OFB. Пока один и тот же ключ + iv используется для каждой ревизии. Это будет означать, что один и тот же поток PRNG будет генерироваться каждый раз, а затем XOR'ed с кодом. Если какой-либо отдельный байт отличается от другого, тогда у вас есть несоответствие, а текст шифрования его сам будет объединен нормально.
Также может быть использован блочный шифр в режиме ЕЦБ, где наименьшее несоответствие будет иметь размер 1 блок, поэтому было бы идеально использовать небольшие блоки. С другой стороны, режим CBC может создавать широко различный шифрованный текст для каждой ревизии и, следовательно, нежелателен.
Я понимаю, что это не очень безопасно, режимы OFB и ECB обычно не используются, поскольку они слабее, чем режим CBC. Жертва IV также нежелательна. Более того, неясно, с чем защищается атака. Там, где использование чего-то типа SVN + HTTPS очень распространено и также безопасно. Мой пост просто говорит, что это можно сделать эффективно.
Почему бы не настроить ваше репо (subversion, mercurial, whatever) на зашифрованную файловую систему и использовать ssh только для подключения?
Используйте rsyncrypto для шифрования файлов из вашего каталога открытого текста в ваш зашифрованный каталог и дешифрования файлов из зашифрованного каталога и вашего каталога с открытым текстом, используя ключи что вы держите локально.
Используйте вашу любимую систему управления версиями (или любую другую систему управления версиями - svn, git, mercurial, что угодно) для синхронизации между вашим зашифрованным каталогом и удаленным хостом.
Реализация rsyncrypto, которую вы можете скачать сейчас, из Sourceforge не только обрабатывает изменения в байтах, но также вставляет и удаляет. Он реализует подход, очень похожий на подход, который упоминается в "The Rook".
Однобайтовые вставки, удаления и изменения в файле открытого текста обычно приводят к тому, что rsyncrypto делает несколько K полностью разных зашифрованных текстов вокруг соответствующей точки в зашифрованной версии этого файла.
Крис Торнтон указывает, что ssh - одно хорошее решение; rsyncrypto - это совсем другое решение. Компромисс:
Вы можете использовать сетку Tahoe-LAFS для хранения ваших файлов. Поскольку Tahoe разработан как распределенная файловая система, а не система управления версиями, вам, вероятно, потребуется использовать другую схему управления версиями поверх файловой системы.
Изменить: здесь расширение прототипа для использования Tahoe-LAFS в качестве внутреннего хранилища для Mercurial.
SVN имеет встроенную поддержку для безопасной передачи данных. Если вы используете svnserve, вы можете безопасно получить доступ к нему с помощью ssh. Кроме того, вы можете получить доступ к нему через сервер apache с помощью https. Это подробно описано в документации svn.
Что конкретно вы пытаетесь защитить?
Используйте Subversion ssh или https для доступа репо. Используйте зашифрованную файловую систему на клиентах.
Посмотрите GIT. Он поддерживает различные крючки, которые могут выполнять работу. См. git шифрование/дешифрование файлов удаленных репозиториев, в то время как push/pull.
Думали ли вы об использовании Duplicity? Это похоже на rdiff-backup (дельта-резервное копирование), но зашифровано? На самом деле не контроль версий, но, возможно, вам нужен все классный материал, но вы не хотите работать с кем-либо еще. Или просто нажмите/вытащите из локального архива Truecrypt и rsync его в удаленное местоположение. rsync.net имеет приятное описание обоих - http://www.rsync.net/resources/howto/duplicity.html http://www.rsync.net/products/encrypted.html - очевидно, контейнеры Truecrypt по-прежнему хорошо работают.
Использовать распределенные VCS и переносить изменения непосредственно между разными клиентами по зашифрованным ссылкам. В этом случае нет атакуемого центрального сервера.
Например, с помощью mercurial вы можете использовать внутренний веб-сервер и подключать клиентов через VPN. Или вы можете связывать наборы изменений и распространять их с зашифрованными письмами.
Вы можете экспортировать зашифрованный раздел жесткого диска по сети и подключить его на стороне клиента и запустить VCS на стороне клиента. Но у этого подхода много проблем, например:
Могут быть и другие проблемы с вариантом B, поэтому забудьте вариант B.
Как и @Commodore Jaeger, используйте VCS поверх сетевой файловой системы с поддержкой шифрования, например AFS.
Как и в некоторых комментариях выше, полезным решением может быть шифровать и локально хранить весь репозиторий и синхронизировать его с удаленным ящиком. Например. при использовании git весь репозиторий хранится в директории '.git' в директории проекта.
Это можно сделать с простой оболочкой script более комфортной.
pro: Вы можете использовать любое шифрование, а также каждый VCS, который поддерживает локальные репозитории.
минус отсутствует, очевидно, некоторые функции VCS, когда несколько человек хотят загрузить свою базу кода (ситуация слияния) - хотя, возможно, это можно было бы устранить, избегая перезаписывания удаленно и слияния локально (что вводит замок, здесь начинается кошмар)
Тем не менее, это решение является взломом, а не правильным решением.
Безопасный источник хранит данные в зашифрованных файлах. Подожди, я заберу это. Они запутаны. И нет никакой другой безопасности, кроме входной двери для обфускации.
Давай, помидор.
Исходя из моего понимания, этого не может быть сделано, потому что в SVN и других системах управления версиями серверу нужен доступ к открытому тексту, чтобы выполнять управление версиями.