Существует ли зашифрованная система управления версиями?

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

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

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

От чего конкретно вы пытаетесь защититься?

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

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

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

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

Да ладно, сегодня понедельник.

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

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

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

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

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

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

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

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

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

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

Вариант A

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

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

Вариант B

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

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

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

Вариант C

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