Выполните настройку для отдельных зашифрованных файлов в проекте C ++

Question

У нас есть проект на C / C ++, в котором мы хотим зашифровать (с помощью GPG) каждый отдельный исходный файл и сделать так, чтобы (в частности, GNU Make) бесперебойно работали (как сейчас с незашифрованным источником).

Если мы зашифровываем только файлы C или C ++, это кажется довольно простым для выполнения с помощью правила, подобного следующему:

%.o : %.cc.gpg %.hh                                                             
    $(GPG) --decrypt $< | $(CXX) $(CFLAGS) -x c++ -c -o $@ -

Однако, если мы начнем шифровать заголовочные файлы, это станет намного сложнее, так как CФайл может #include любое количество заголовков.Поэтому мне кажется, что сначала мне нужно создать список зависимостей, затем расшифровать все зашифрованные и скомпилировать.В идеале расшифровка должна выполняться в оперативной памяти, а не оставлять дешифрованные файлы в процессе компиляции.

Некоторые примечания в ожидании комментариев, которые я получу:

• Рабочий процесс пользователей будет включать плагины GPG для их редактора, но все остальное должно быть как можно более плавным (т. Е. Традиционный рабочий процесс Linux svn + make + gcc на основе командной строки)
• Мы используем subversion для управления исходным кодом.Мы знаем и согласны с тем, что источник хранится в виде двоичных двоичных объектов (как и последствия этого, например, взлом svn diff)
• Репозитория Subversion находится в зашифрованной файловой системе (LUKS), и доступ осуществляется только через https
• Это требование к управлению
• В моем веб-исследовании этой проблемы я видел, как многие люди выступают против шифрования каждого исходного файла.Как я уже сказал, это требование управления.Но одна вещь, на которую не ссылаются эти аргументы, это защита исходного кода от системных администраторов.Да, в какой-то момент вы должны доверять людям, но наш источник похож на рецепт кока-колы: если он не контролируется, это может буквально разрушить компанию.Так зачем рисковать?

Answer 1

У вас есть две проблемы: 1) расшифровка файлов в процессе сборки и 2) сохранение открытого текста в оперативной памяти. Второй немного вне моей области; Я бы предложил рабочие места с воздушным зазором с ночной очисткой дисков и действительно хорошую систему аудита, и любой, кто указывает на недостаток безопасности, получает вознаграждение, а не наказание . В любом случае, давайте предположим, что вы решили эту проблему. (На данный момент вы можете просто расшифровать всю кодовую базу и работать в обычном режиме, но давайте попробуем найти более подходящее решение.)

Для расшифровки вы на полпути. Вместо расшифровки в правиле %.o я бы разбил его на отдельные правила:

%.cc : %.cc.gpg                                                             
    $(GPG) --decrypt $<

%.o : %.cc %.hh                                                             
    $(CXX) $(CFLAGS) -x c++ -c -o $@ -

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

Если вы используете цивилизованный компилятор, такой как g ++, вы можете (в общем) сгенерировать список зависимостей с помощью g++ -M и использовать его для написания "умного" %.o правила, такого как описано здесь , которая автоматически и незаметно решит все проблемы с зависимостями.

Проблема в том, что вы не можете сначала использовать g++ -M, потому что вы находитесь в вязком круге: вы не хотите расшифровывать все заголовки, только те, которые вам нужны, поэтому вы не можете делайте расшифровку, пока не узнаете, какие заголовки вам нужны, но вы не узнаете об этом, пока не создадите файлы зависимостей, что означает запуск g ++, но g ++ выдаст ошибку и завершит работу, если требуемый заголовок еще не существует.

Так что мы будем обманывать. Предположим, у нас есть отдельный каталог, полный пустых заголовочных файлов с теми же именами, что и настоящие заголовочные файлы (тривиально построить / сохранить с помощью Make). Мы можем указать g ++ (и Make) искать там заголовки, которые он не может найти в обычном месте. Этого недостаточно для фактической компиляции объектов, но достаточно для запуска g++ -M без ошибок. Список зависимостей, который он создает, будет неполным (потому что реальные заголовки могут #include друг друга), но этого достаточно для первой итерации . Make может расшифровать эти заголовки, а затем начать заново; когда результаты g++ -M совпадают со списком из предыдущей итерации, процесс завершен, все необходимые заголовки были расшифрованы, и компиляция может начаться.

Достаточно ли этого контура или вам нужна помощь с гайкой и болтами?